Hi,
> Now what happen if I want to add usecases (e.g. login) to the overall
> lenya site. Generally speaking, embedding extra content to a lenya
> site (like a portal). Thinking in standards leads us to cocoon portals
> and the portlet specifications. We have to find ways to integrate
> them into lenya in an easy and standardized way.
This is what I have been thinking about for a long time. (Compare the
dicussions about publets - though I think publets today turned out to be
something entirely different that what we mean originally - and the
useage of XInclude - see Wiki). This is how I discovered most of those
problems. But I haven't thought them through and come up even with a
suggestion yet. But I am working on it.
Regarding the portlet spec: I had read that, but if I got it right, this
still does not address referencing fragments of a page for inclusion,
does it?
Talking about standards, I think everyone of us should have read this
document:
http://www.faqs.org/rfcs/rfc2718.html
(I wasn't aware that this exists until today either.)
Regards,
Torsten
Thorsten Scherler schrieb:
On Tue, 2005-08-16 at 10:13 +0200, Torsten Schlabach wrote:
What I am concerned with for quite some time is our URI mangling magic
stuff. IMO he have way too much semantics and implicit contracts in our
URIs, especially when it comes to embedding (a page and pictures on the
page) or linking pieces (internal and external links) together.
I was hoping that JCR as a well thought through, standardized and in the
near future well known standard API will provide a chance to clean this up
and improve. For example, by linking not to a pathname but to a UUID. This
would take lots of ambiguity out.
Yes. The UUID will provide a unique id to a node (e.g. document), but it will
not
automatically harmonize the way to access it. ;-)
I am more concerned about the way we handle parameters in e.g. our usecases.
I do not see the point to parse them as hidden input fields into the html output form.
We should store them either in the user-session or better a transaction-session.
Enabling cforms out-of-the-box will provide standard methods and widgets for handling
transaction, validation, etc. The reuse of cforms is really worth the extra work
(instead of 1 jx file you have 3 different ones).
Now what happen if I want to add usecases (e.g. login) to the overall lenya site.
Generally speaking, embedding extra content to a lenya site (like a portal). Thinking in standards
leads us to cocoon portals and the portlet specifications. We have to find ways to integrate
them into lenya in an easy and standardized way.
Still there are many parts in the code where I personally would store the data in a bean and add
it to the session/request. That will help to reuse this data more efficient.
The good news is that 1.4.x with e.g. the usecase-fw is already addressing many ways to overcome
the "URI mangling magic" by providing more standardized ways of doing things.
That said I as well agree with you to say, we should focus on a jcr only implementation of the lenya repository
for now. That is fitting in nicely with our drive to standards and helps to finally release 1.4.x.
The doco branch will address the svn issue and we all (cocoon, forrest and lenya) can help making it happen *quick*.
Helping hands are always welcome (devs and user included). ;-)
salu2
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
