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
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to