cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henning von Bargen <H.vonBar...@Triestram-Partner.de>
Subject AW: AW: Examples of Cocoon
Date Mon, 11 Sep 2000 07:29:09 GMT
> -----Urspr√ľngliche Nachricht-----
> Von:	Isidoro Martinez [SMTP:isidoro.martinez@expandedmedia.be]
> Gesendet am:	Montag, 11. September 2000 09:15
> An:	cocoon-users@xml.apache.org
> Betreff:	Re: AW: Examples of Cocoon
> 
> I'm agree, throwing untested code can represent more a problem that a
help.
> 
> If we want that a framework as Cocoon works in real applications
> we should provide it with all the functional things that everybody needs
and
> everybody has
> done or used.
> Maybe the first step idear should try to identify those points and work on
> them.
> It doesn't means they are related only with Cocoon; these points are
'generic
> issues'.
> Here some suggetions:
> 
> 1) Database persistance.
> There are several proposals on the Net. It would be nice if we can
integrate a
> good solution
> into the Cocoon framework (waiting for JDO?)
> 
> 2) List management.
> Something used thousands of times and everybody has to rewrite its own
code!
> It could be nice to have a kind of interface, abstract class that should
> provide
> some basics functionalities:
> - Only a group of records are kept in memory. Buttons for Next/Prev.
> - The list must be refreshed each time it is visited again (configurable
> issue?)
> 
> 3) Form validation.
> Again provide some skeleton that provides:
> - After the form is validated, we know which fields are not valid an error
> messages related
> with each wrong issue. Then we can display a complete error message or
mark the
> wrong fields
> in the form.
> 
> 4) User tracking/personalization
> Something that the professional web sites ask more and more is a way to
track
> the user 'movements'
> This valious information can be used afterwards to 'analyze' the user or
to
> personalize the web
> site according with the things we know about the user.
> 
> I know these things are not Cocoon specific, but they must be part of a
web
> framewotk if we
> want that it is successful.
> Of course the list is not complete and well defined.
> I would like to work on it and try to find together nice solutions! :-)
> 
> Isi,

I agree, your 4 suggestions are the most important.

> 
> Ulrich Mayring wrote:
> 
> > Henning von Bargen wrote:
> > >
> > > IMHO you should submit everything that is working, whether it's ugly
code
> > > or
> > > unstable or whatever.
> > > Maybe the submitters should be encouraged to comment about the quality
of
> > > their examples.
> >
> > Then again, maybe we should establish reference platforms, with which to
> > test contributed code. I think it is not very helpful to just throw
> > everything untested and only half-working onto the users.
> >
> > Ulrich

Would anyone who is not totally brain-damaged submit untested or non-working
examples
and sign them with his name and e-mail address?
I hope not.
But if you've developed something that works fine on your platform 
and you think it could be useful for other people, you should be able to
submit it
without testing it on dozens of other platforms 
(OS, Cocoon versions, web servers, servlet engines).
One thing you should do is to tell exacty on which platform(s) you tested it
and how good it was working there.
Henning



Mime
View raw message