Re: [vote] FOM design methodology
Giacomo Pati wrote: I'm late, I know ;-) But welcome anyway!
More on FOM
Hi friends, The following items reflect the discussions Stefano and I have had around the FOM: - The load(uri) global function should be supported. This is clearly needed for nested source file inclusion (which map:script does not support). - The cocoon.releaseComponent(component) method should be supported in conjunction with cocoon.getComponent(id). Further discussion is needed about whether the FOM implementation should automatically take care of releasing components. - There should be unrestricted access to all components via cocoon.getComponent(id). Among other goodies, this will give indirect access to Actions and Modules without providing explicit FOM support for them. Access to request input modules, in particular, should account for request.getURI(). - Access to continuation objects should be provided. var kont = sendPageAndWait(uri, data) This is deemed necessary as certain continuation usage patterns may call for explicit, programmatic invalidation of continuations. - Properties - id - Methods - getParent() - getChildren() - invalidate() - Events - onExpiration() What do you guys think? Ricardo
Re: More on FOM
Reinhard Pötz wrote: - There should be unrestricted access to all components via cocoon.getComponent(id). I'll implement getComponent( id ) and releaseComponent( component) ASAP because the current flow implementation exposes the component manager and this leads to a serious bug! If you have more than one user the component manager can become null. This can be very annoying if you want to train some people ... Cool :-) Among other goodies, this will give indirect access to Actions and Modules without providing explicit FOM support for them. Access to request input modules, in particular, should account for request.getURI(). AFAIK many of them need the object model and this is not provided by the flow so I think you have no chance to use the actions and input modules which need objects of the object model. Am I right here? Yes, you are... :-( - Access to continuation objects should be provided. var kont = sendPageAndWait(uri, data) This is deemed necessary as certain continuation usage patterns may call for explicit, programmatic invalidation of continuations. - Properties - id - Methods - getParent() - getChildren() - invalidate() - Events - onExpiration() sounds good. It should also be possible to create your own continuations objects without sending a page. See the JXForms implementation which needs this to provide previous/next-navigation. Yes, creating continuations without sending pages is all-important. I'll add all those things to the proposal ASAP. Hey Reinhard, you're a committed committer, cool! Regards, Ricardo
Re: More on FOM
Sylvain Wallez wrote: Ricardo Rocha wrote: The following items reflect the discussions Stefano and I have had around the FOM: - The load(uri) global function should be supported. This is clearly needed for nested source file inclusion (which map:script does not support). - The cocoon.releaseComponent(component) method should be supported in conjunction with cocoon.getComponent(id). Further discussion is needed about whether the FOM implementation should automatically take care of releasing components. Hehe, I should go to Ecuador, as I advocated both ;-) You're welcome anytime my friend! :-) I suggested that components being heavyweight resource, allowing them to cross continuation boundaries should be prohibited. Automatic release doesn't seem a good solution to me, as it would mean that script variables would hold released components, thus leading to unpredictable behaviour (think about stateful pooled components). So my opinion is to raise an error if there are some unreleased components when a continuation is created. This will allow users to quickly learn the safe practices related to component management in flow scripts. I see your point Sylvain. Your solution sounds somewhat draconian but it's probably the only safe bet... The question then becomes: does anyone envision real-world scenarios in which stateful components *are* needed across continuation boundaries? (if so, imo, it might imply curent Avalon component management isn't safe for continuations) Or can we *always* formulate our flow so that we don't need to keep component state across continuations? (for example, database connections can be acquired/released as needed precisely because they're pooled). On a separate thread, if *all* acquired components *must* be released prior to creating a continuation... wouldn't it make sense for the FOM implementation to automagically release them?? I know it may sound dangerous at first, but then again it would relieve developers from that tedious, anti-scripting release idiom... - There should be unrestricted access to all components via cocoon.getComponent(id). Hehe again ;-) Hahaha! There's nothing quite like the flavor of victory, is there? ;-) Among other goodies, this will give indirect access to Actions and Modules without providing explicit FOM support for them. Access to request input modules, in particular, should account for request.getURI(). Two remarks here : - if we give access to request.getURI through an input module, then why removing it from the request object ?? Until proven otherwise, I don't think getURI() is _needed_ by the flow, so the request object shouldn't expose it. Imo, the flow renders actions (and modules outside the sitemap) unnecessary, so we shouldn't encourage their continued use by providing FOM-level support for them. The idea, in the long term, is to stop using actions (and xsp's, for that matter) in favor of the flow. That said, *indirect* access to modules and actions would satisfy short-term, transitional requests to allow reuse of such legacy components from the flow (if only by popular demand :-)). - modules need the object model and actions need it also, along with a (Cocoon) resolver and a redirector. How will the flow be able to access these objects to pass them to the components ? Yes, you're right. Reinhard also pointed this out. IMO, the second point calls for some refactored interfaces since the (Excalibur) resolver is now a regular component and we decided some time ago to make the object model accessible through the Avalon context (don't know if it has been implemented, though). Yes, this solution is clean. If the object model is available legacy actions would be accessible. What I'd oppose -in any case- is giving actions/modules first-class status in the FOM... Ricardo
Continuation patterns (too long!)
Hi friends,
Is this a rant? A random thought? A pontification? Well, let's say it's
just a personal story (and a concern) I want to share with my fellow
Cocooners...
Someone said continuations can be grasped in five minutes, but it
may take a lifetime to master them :-)
When first introduced to web programming with continuations I was
profoundly impressed to see how continuations reinvert IoC and turn
event-oriented programming into good ole' sequential programming.
I was even more impressed to see how -with continuations- the infamous
back button could become in fact a new, all-powerful tool for what-if
scenarios and exploratory browsing.
Boy, is this a triumph of spirit over matter! :-)
After such intellectual orgasm it followed naturally that -from now on-
all my EJB-based webapp development *had to* be developed using Cocoon's
flowscript.
Unsurprisingly, I was rapidly hit by real-life's nasty habit of
impairing golden hammers:
After executing a database-modifying EJB method from the flow, I saw how
invoking the same continuation twice resulted in inconsistent database
state! Obviously, database modifications reflect all updates made
throughout the session, regardless of continuations...
In general, any store will reflect changes made in time. Continuations
only preserve _program_ state. Store state has to be accounted for
separatedly. Thus, continuations wouldn't spare me from having to keep
some sort of explicit dialog control after all...
Since I was playing with a utility screen Javascript object (not
unlike Chris' [JX]Form wrapper) I was able to easily add a low-level
sequence number check to ensure obsolete continuations were detected
and rejected. Easy hack: it didn't propagate to my application-level
flow code.
All of my dialog pages had a Cancel button users could click on at any
time to abort the current transaction. Checking to see if it was pressed
became sort of an aspect for every submitted page.
Because pages can be sent (executed) at any function call nesting
level I decided to implement cancellation processing as a Javascript
exception that propagates all the way up to the top-level sitemap
function dispatcher. Later on, I realized it would be more elegant (and
continuation-aware) to create a globally accessible continuation inside
the dispatcher and use it as an escape procedure. Upon invoking such
continuation, all other outstanding continuations should be invalidated.
I also faked a Javascript component manager which -in absence of the
upcoming Cocoon blocks- would provide me with subsitemap-specific
components for use in my flow.
By combining form objects, local components and [remote] EJB's, I could
keep my flow logic *strictly* flow-related:
...
dataModel.dateFormatter = components.dateFormatter;
...
welcomeScreen.execute(dataModel);
dataModel.requestData =
requestDataScreen.execute(dataModel);
dataModel.requestAnalysis =
requestManagerEJB.analyzeRequest(dataModel.requestData);
if (requestAnalysys.evaluation == APPROVED) {
confirmationScreen.execute(dataModel);
requestManagerEJB.processRequest(dataModel.requestData);
} else {
sorryScreen.execute(dataModel);
}
This was definitively approaching nirvana: flowScript gluing components
across application layers. No misplaced business logic, no cluttered
controller logic, absolute separation of concerns.
But then I realized I had to deal with releasing stateful components...
Sylvain and I have addressed the infamous automatic component
releasing problem which stems from having to account for continuation
trees. His harsh solution (no components leased at continuation
creation) seems to be the way to go...
If I'm to follow my intutition -and my own experience- I'd bet many
Cocoon developers tend to think in terms of a _single_ outstanding
continuation that reflects the webapp's expected flow of execution.
(It was because of such incomplete mindset, btw, that I first thought
acquired components could be automatically released upon sitemap
function completion...)
These and similar experiences suggest web programming with continuations
is an uncharted, brave new world whose deep ramifications we -mere
mortals, non-Lisp gurus- are only beginning to grasp...
Clearly, we need to come up with web-oriented continuation patterns that
reflect real-world application constraints. (Does it make sense to
reuse continuations for form validation? How do we implement one-shot
or linear continuations for transactional dialogs with remote servers?)
The core Continuation implementation is superb. The FOM is rapidly
approaching a stable form. The next challenge is understanding how to
take advantage of this tremendous power while avoiding to shoot our
boots.
Just food for thought...
Ricardo
Re: looking at linotype
Jeremy Quinn wrote: Since the login() method calls 'cocoon.createSession()', should the 'logout()' method not invalidate the Session? Is there a method available in the FOM to do that? I could not work out what I guess cocoon.session.invalidate() should do the trick? Ricardo
Re: [vote] Reinhard Potz as a Cocoon committer
+1, welcome
Re: [vote] FOM design methodology
Stefano Mazzocchi wrote: 1) big to small - give users all possible freedom and restrict that freedom once we understand potentially problematic usages. 2) small to big - give users the least possible freedom based on some required functionality and grow as the users express their needs. +1 for big to small
Re: [vote] FOM design methodology
Joerg Heinicke wrote: 2) small to big +1 from me Ricardo Rocha wrote: Stefano Mazzocchi wrote: 1) big to small - give users all possible freedom and restrict that freedom once we understand potentially problematic usages. 2) small to big - give users the least possible freedom based on some required functionality and grow as the users express their needs. +1 for big to small But this *must* be an error ;-) Sure it is, shom! :-) So I stand corrected: +1 for small to big The FOM design that was proposed by myself and Ricardo follows methodology #2. Joerg
Re: C2.0.4: Strange XSLT behaviour in logicsheet when matching text() nodes (resent)
Sylvain Wallez wrote: IIRC (but don't ask me why), the XSP engine wraps every text node from the XSP file into xsp:text elements. In the original implementation text nodes were preprocessed and escaped as string constants in accordance to the rules of the target programming language. This took place prior to applying the core logicsheet, where xsp:text nodes were to be transparently output as quoted string constants. An alternative to this was using XSLT extension functions to perform string escaping inside the core logicsheet itself. This was rejected at the time because not all XSLT processors supported extensions and they were considered not portable. Along the way, the XSPMarkupLanguage class was rewritten as a SAX processor and the language-specific escaping was dropped in favor of... XSLT extensions inside the core logicsheet :-) So xsp:text is probably a venerable fossil today. That said, if it ain't broken... Ricardo
Re: C2.0.4: Strange XSLT behaviour in logicsheet when matching text() nodes (resent)
Sylvain Wallez wrote: Ricardo Rocha wrote: snip/ So xsp:text is probably a venerable fossil today. That said, if it ain't broken... Ah yes, I remember that, now. Gosh, the ancient times of Cocoon 1.x... Thanks for refreshing our memory, Ricardo. In fact, I was refering to the first Cocoon *2* XSP implementation. But, yes, this is reminiscent of good ole' Cocoon 1...
FOM and stateful components
As originally proposed by Stefano, the FOM exposes a getComponent(id) method but not a corresponding releaseComponent(component), as Sylvain was quick to point out. I agree with Sylvain that releaseComponent() is indeed needed for stateful, pooled components. Btw, I'm sure when Stefano mentioned stateful components being questioned he referred to *EJB* stateful session beans that keep state on behalf of a remote client. In this arena, it's felt that keeping session state is best done at the webapp layer rather than inside the EJB container. But that's another matter... *Avalon* stateful, pooled components, OTH, _require_ to be released after use. That said, using try/catch blocks in Javascript to ensure proper stateful component release looks anti-scripting to me. In an ideal world, the flow implementation should take care of this aspect for the flow developer. Of course, I do see such a guarantee is easier hoped for than implemented. Because of continuations, automatically releasing components at the end of request processing is clearly not appropriate. Things are further complicated by the fact that continuations can be abandoned. How should we deal with active stateful components in this case? Even if we hook into continuation expiration, this could still lead to excesive tying up of pooled heavy-weight components. Should we reclaim components at the end of sitemap-invoked function execution? This makes more sense because function completion can span across requests. Performing component auto-releasing at the end of sitemap-invoked function completion (whether because of return or exception) seems a reasonable thing to do because, typically, such function call will embody a complete interaction between the user and the application. If any components were needed during that process it's ok to relase them at use-case completion. However, it would preclude keeping components in use across flow functions. Would this truly limit flow usability? What about specifying a retention policy (session, function) upon acquiring components? getComponent(id[, scope]) What do you guys think?
Re: extending XSP base call
Konstantin Piroumian wrote: From: Geoff Howard [EMAIL PROTECTED] Thorsten Mauch wrote: I like to add some common methods. As a pure jave programmer I hate logicsheets ;( So is it possible to extend the the class XSPGenerator and tell Cocoon to use this class as a base class for the XSP ? No. See xsp.xsl Would this be a bad feature to add? It would be a simple xsp:extend tag, no? There's something like this possible in JSP. I'd suggest to add an attribute like: xsp:page extends=com.bla.mla.MyClass/ Why? What could one achieve with inheritance that cannot be achieved, for instance, with delegation? Ricardo
President Of India Advocates OSS
Found this on Slashdot: http://timesofindia.indiatimes.com/cms.dll/html/uncomp/articleshow?msid=47799819
Re: org.apache.cocoon.components.language.programming.java package
Paul Hammant wrote: (interloping from the AvalonDB server project) We'd like to be able to use a technique where we compile SQL SELECT statements into Java class actions. OK, so this is a non-rendering class, but it has similar aspects to JSP and XSP pages in that it is cached and used again later. My reason for popping into this list is to basically ask two questions: 1) Is the org.apache.cocoon.components.language.programming.java package suitable for reuse, or is it too tightly coupled with Cocoon? 2) Can we think about moving the package to Avalon's Excalibur? ( I can do the addition work to Avalon's CVS tree, you folks switch your impl...) I'd say the packages under org.apache.cocoon.components.language, in general, aren't really coupled to Cocoon. The programming.java package in particular could be reused with practically no change. Ricardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [donation]XML:DB pseudo protocol
I'd like to propose Gianugo Rabellino as a new commiter to the cocoon community. He has produced alot of patches in the past and is very engaged in the dbxml parts of cocoon which I think would be best if he can do it directly in CVS rather than badging us with patches. Enthusiastic +1 for Gianugo 5.0! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [vote] Ricardo as Apache representative in JSR-152
John Morrison wrote: I'd be quite happy for him to do the job - but I don't think that I've heard him say he would like to yet! :-)) I think I've already said so but here it goes: I'd like to participate on behalf of the Apache Cocoon community and, in particular, as a carrier of our project's ideas and experience on dynamic XML generation. Un saludo a todos, Ricardo Stefano Mazzocchi wrote: People, there is no official process to make this happen, but in the past, the dev community indicates the person, then we pass it over to the Apache JCP Commitee for official approuval. So, first step, is to indicate whether you guys would like him to be our representative in that JSR (remind you: about the next JSP release). So, please, place your vote. Of course, mine is +1. -- Stefano Mazzocchi One must still have chaos in oneself to be able to give birth to a dancing star. [EMAIL PROTECTED] Friedrich Nietzsche - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] === Information in this email and any attachments are confidential, and may not be copied or used by anyone other than the addressee, nor disclosed to any third party without our permission. There is no intention to create any legally binding contract or other commitment through the use of this email. Experian Limited (registration number 653331). Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
