Re: [gyrex-dev] Gyrex Setup worked

[Christoph Rueger <christoph@xxxxxxxxxxx>]

HI Gunnar,

On Wed, Feb 3, 2010 at 9:04 PM, Gunnar Wagenknecht
<gunnar@xxxxxxxxxxxxxxx> wrote:
>
> Am 03.02.2010 18:03, schrieb Christoph Rueger:
> > ".metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.gyrex.preferences.prefs"
>
> > Is this actually customizable? What is this location in a server environment with multiple machines and e.g. a central file-server or database.
>
> Yes. This is fully customizable. Right now it's the "instance" scope.
>
> Eclipse preferences work with different scopes.
> http://tinyurl.com/eclipse-preferences-api
>
> The out-of-the box scopes are default, configuration and instance scope.
> They match the OSGi locations.
>
> default - set by developer
> configuration - "<eclipse>/configuration"
> instance - "<workspace>"
>
> In the Eclipse SDK most configuration options are stored per workspace,
> i.e. in the instance scope (eg., the installed JDKs, PDE target
> platforms, editor settings, etc.). When you start Eclipse, the workspace
> chooser dialog remembers the last-recently-used list in the
> "configuration" scope, i.e. per Eclipse installation. You can run
> multiple instances out of a single installation.
>
> In Gyrex we introduced the "platform" scope. The idea is that we have a
> global scope which stores configuration options in a database or LDAP or
> shared file-system. Another idea was to store the preferences in the
> instance location and just replicate it. Currently, they are stored in
> the instance location because that was the simplest implementation.
>

That's great. Ok I first have to get familiar with those concept of
Eclipse preferences.


> > Yes, I would definitly try to build a simple sample application. I would prefer something really simple like a Weblog with "Posts" and "Comments". To avoid unnecessary dependencies we could try to avoid a Database and just write to the current user session or something. Just a simple persistence interface but let the HTTP Session be the DB. that way we avoid lots of heavy frameworks like Hibernate etc. I think the goal should be to show people where the important hooks are to build their own application. This sample app should answer the following questions:
> >
> > * What is the first thing I need to do to build an own app from scratch based on gyrex?
> > * If I have a servlet XYZ, where do I configure (or what glue code do I need to write) it so that I can call it via http://localhost/myapp/myservlet
> > * My App wants to use a Logger, what code do I need to write to use Gyrex Logger
> > * my app wants to store some properties (configuration data) somewhere. Where is the best place to do this
> >
> > In the end writing a new app on gyrex should be as easy as Ruby on Rails. *
>
> Great. So let's make it that simple. :)
>
> But how does Ruby on Rails does it? Don't they generate templates for
> you out of the box? I imagine we could something similar with PDE
> template projects but first we need to spend a little time creating such
> a working template.

Yes, they do a lot with generating templates what they call
"scaffolding" but it not the most important thing.
More important about the RoR way is the "Convention over
configuration" approach and sensible defaults. A lot of things just
work out of the box with as little code as possible, as this is
considered the "default". e.g. they have a default folder structure
for templates, images, controller and model code. if you stick to this
convention then things are easy. you can customize if you want but
then it gets a bit harder.

There is just something working veruy early. After that default works,
you can inspect it and start customizing it. I can recommend this
15-Minutes screencast where they are creating a blog app.
http://media.rubyonrails.org/video/rails_blog_2.mov

I don't think Gyrex should copy RoR, but what my point is: getting up
to speed with RoR is extremely simple, because simple things are
simple.
I like the ideas and concepts behind RoR a lot. Frameworks are so damn
complex and powerful those days, so the goal should be to conquer this
complexity and make it easier for people to start using a new
framework like Gyrex. That's easiest if they see a benefit as fast as
possible, and what is more beneficial than a working application  :)

I think the next steps are that I understand how to build an app and
then we can think about how to make build new apps as easy as
possible.



> So, next question ... do you prefer working with Eclipse extension
> points or with OSGi services? The former is easier to get started with
> because it allows to just start writing the servlet code. The latter
> allows more dynamic control but requires writing more code (activator,
> dealing with OSGi service, etc.). If you like, we could try both ways.
>
> First step is to create a new plug-in project in any case.
>
> A) "my.app"
> B) "my.app.registry"
>
> "my.app" will use OSGi services.
> "my.app.registry" will use the extension registry.
>

I haven't worked with Extension points yet, but I think both things
make sense. Maybe when we build the app, we should start with the
easier thing first and later extend it. This could also be captured in
a Blog-series which constantly evolves based on the sample-app but
always extends it a bit or does somethings with different approaches.

Christoph

>
> -Gunnar
>
> --
> Gunnar Wagenknecht
> gunnar@xxxxxxxxxxxxxxx
> http://wagenknecht.org/
> _______________________________________________
> gyrex-dev mailing list
> gyrex-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/gyrex-dev