[Helma-user] Rocket the Super Rabbit

[Hannes Wallnoefer]

Hi Samuel,

2007/5/4, Samuel Oey <sam at sumaato.net>:
> Hi Hannes,
>
> I've had a quick look at jala.Form: It looks very promising! And yes, let's
> bundle the efforts. I don't really know if i get you idea of
> decentralization/centralization right. Let me explain it from my point of
> view. What I want is a central (typed) data model, that can be used to
> automatise/ease most of the common web developer tasks. It should be
> designed the way, that you only have to define that model add some CSS and
> will have the most basic input/output/data handling functionality ready.

Yes, that's wonderful, I share most of what you describe. Where my
view differs is mostly in how much to put into the extended
type.properties: data definition stuff yes, but I'm not sure about the
validation stuff, and even less the html form element description. I
would just prefer to have them in another layer, probably expressed in
JavaScript code rather than a properties file.

But then, maybe all this should and could be expressed in JavaScript
rather than type.properties (there's no reason we can't have a JS API
for type mapping/model description), so that objection would vanish.

I also think that the automatically generated interface should be
thought of as admin interface, with the possibility to create the
"real" interface from scratch (see below).

> (Maybe it would be better to implement sth. like that in helma core)  This
> should be as easy as possible and is centralized for that reason. I think

I don't think so. Helma core should provide the necessary means (i.e.
API), but it's nice to have the details in JS.

> the point is, how to enable specialisation of this basic functionality. The
> different tasks like data validation, form rendering etc. can then be
> handled decentralized by specialised classes - no problem with that. (As
> long as the user don't have to install dozens of libs because of all the
> dependencie s ;) )

Yes, I agree, see above. As I said above, it's also possible that the
automatic GUI would just be treated as admin interface for basic CRUD
operations (create, read, update, delete). The real/public interface
would be handcoded, of course building on some powerful modules
(possibly the same used by the admin interface). I think this is the
way it's done in the Django framework.

> There is no db evolution/versioning in the rocket.Db. What would be the
> reason to put implement this?

Oh, just a question. Databases schemas evolve, and so it's nice to
have some support for that. Somethign I've seen elsewhere evolves up()
and down() scripts to automatically move database schemas up and down
the evolutionary scale.

> To start the modelling from an existing db is in fact a process I also
> thought of and is not implemented yet only because of a shortage of time.
>
> So where should this evolve to? I would like to see Rocket combined with
> more elaborated form/output generation/validation and skinability. Maybe
> someone will need/add support for other DBs? I don't know if it's in the
> scope - but maybe it is an idea to think of Ajax input/output support.
>
> On the long run I would like to see some of this functionality included in a
> cleaned Helma core itself. It should then be possible to prototype
> Helma-Apps from scratch up to the most elaborated Ajax functionality.

Yes, sure. Your help to get us there is welcome!

> is so much momentum in the Javascript/Ajax development. Sadly ROR is the big
> player on the server side development. But with the right efforts, maybe
> Helma could catch up.
>
> BTW: Is there any chance to see the ECMAScript 4 standard implemented in
> Rhino some time?

Some people are thinking about it. Don't expect it in the near future.

hannes

>
> Samuel
>
> 2007/4/30, Hannes Wallnoefer <hannes at helma.at >:
> > Hi Samuel,
> >
> > I just skimmed through the code quickly. It's definitely interesting.
> > I think I would prefer a less decentralized approach, meaning I don't
> > think that database design and html form generation/handling should be
> > defined in the same spot. But it's a matter of taste, really.
> >
> > For the form handling stuff you may also want to check out what's
> > going on in jala: there's a jala.Form module which I think will be
> > part of the next major release:
> >
> https://opensvn.csie.org/traccgi/jala/wiki/JalaModules/Form
> > https://opensvn.csie.org/jala/trunk/docs/jala.Form.html
> > https://opensvn.csie.org/traccgi/jala/ticket/39
> > I think it may make sense to combine this with what you're doing.
> >
> > For my part, I'm especially interesteed in the database features you
> > have in there. Is there any kind of versioning/db evolution support in
> > there? Support for starting from an existing database? In what
> > direction, if any, would you like to see this evolve?
> >
> > Hannes
> >
> > 29 Apr 2007 09:02:24 -0000, Samuel Oey < sam at sumaato.net>:
> > > Hello List,
> > >
> > > I discovered Rabbit some weeks ago and really like to push the
> prototyping
> > > idea. Here is what I worked on my spare time the last weeks. In large
> parts
> > > it's based on Rabbit, but I break the code appart in different parts and
> > > introduced some new stuff. Grab the code and do with it whatever you
> want.
> > > I'm hoping for discussions and some interest in boosting the helma
> > > development process.
> > >
> > > Pick the source here:
> > >
> > > http://typolis.net/developer/stories/12133/
> > >
> > > Features:
> > >
> > >  * Metadata for Hop Object prototypes
> > >  * Automatic form/input generation
> > >  * DB/Table generation (MySql)
> > >  * Creation of the model from existing source
> > >  * Creation of folders/type.properties from the model
> > >  * Basic permission management/access control
> > >  * Basic List / Object viewer
> > >
> > > _______________________________________________
> > > Helma-user mailing list
> > > Helma-user at helma.org
> > > http://helma.org/mailman/listinfo/helma-user
> > >
> > _______________________________________________
> > Helma-user mailing list
> > Helma-user at helma.org
> > http://helma.org/mailman/listinfo/helma-user
> >
>
>
>
> _______________________________________________
> Helma-user mailing list
> Helma-user at helma.org
> http://helma.org/mailman/listinfo/helma-user
>
>