Re: Use of generated stylesheets
Olivier Billard wrote:
Hi all !
I posted my question on Users, but it seems more appropriate to ask
it here.
I want to use a generated stylesheet with an XSL transformer, using
the cocoon protocol.
But I get this error :
org.apache.cocoon.ProcessingException: Unable to get transformer
handler for cocoon://picto-filter.xsl:
org.apache.excalibur.xml.xslt.XSLTProcessorException: Exception in
creating Transform Handler
This exception often occurs when the stylesheet is not correct. You
should have more details about what goes wrong either in some chained
exception, or in the log files (Xalan often logs the error before
raising the exception).
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: More on FOM
Ricardo Rocha wrote:
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.
Hehe, I should go to Ecuador, as I advocated both ;-)
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.
- There should be unrestricted access to all components via
cocoon.getComponent(id).
Hehe again ;-)
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 ??
- 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 ?
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).
- 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.
What do you guys think?
Read inline !
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: More on FOM
Ricardo Rocha wrote: 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! :-) Cool ! This is one of the good things of Apache : world-wide friends, ready to welcome you for good time and geek talks :-) 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). Databases connections are a good use case. IMO, the sequential nature of a flow script will make people want to keep stateful components as the do in standard code, as it is somewhat unnatural to release a connection just before a sendPageAndWait() and then look it up just after. The modified Rhino intepreter has some extensions to exception management to allow clearing and restoring variables when a continuation is suspended/reactivated. This will be very useful in large scripts when a continuation is suspended several function call deeper than the location where the component is used. 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... Once again, I agree that explicit release is very unnatural. But automagic release is good only if we can have some automagic restore. For this we can have getComponent() actually return a proxy to the real component, and have the proxy do a release/lookup when a continuation is suspended/reactivated. But as elegant this may seem, this won't work : stateful components have... a state, and a release/lookup cycle destroys this state. So I don't see any other solution... - 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? ;-) Mmmh... it's not about victory in the fight meaning, where there's a winner and a looser. We all win in discussing our thoughts and taking good ideas where they come. This time these are mine and, well, this feels good ;-) 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. Actually, I think that if the flow needs something from the URI, this information should be passed by the sitemap through map:parameters in the map:call. The sitemap is responsible for handling the URI space, including extracting information from it for other components. 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 :-)). Ok. So we allow some abuse to satify transition of legacy applications or code
Re: [Flow] getComponent(id) implementation
Carsten Ziegeler wrote:
Reinhard Pötz wrote:
The Cocoon object of the FOM has the method
Component getComponent(id)
It should return any component but no sitemap components. This means we
only return components defined in the roles file(s). How can we check if
it is an allowed component?
Any ideas?
I think the simplest solution is to use the correct component manager that holds only the components configured in roles/cocoon.xconf. This is the component manager of the o.a.c.Cocoon object.
Each sitemap as its own component manager for the sitemap component, they are linked in a hierarchy to the above mentioned one.
Sorry if I missed something (was offline for several days -- lots of
emails to read), but why is it necessary to make a distinction between
sitemap components and other components ?
What could be the possible use of e.g. a transformer in a flowscript ? I
can't see one... So why build complicated fences to prevent something
that is IMO doesn't even make sense ?
Furthermore, and this is what triggered this answer, restricting
getComponent() to the top-level CM goes strongly against the upcoming
blocks and the fact that map:components is nothing but a regular
.xconf declaration.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [Flow] getComponent(id) implementation
Carsten Ziegeler wrote:
Geoff Howard wrote:
Do we want to force people to edit cocoon.xconf to call their own business
components from the flow? I thought Stefano proposed checking for
SitemapModelComponent and disallowing it? Would that prevent looking up
a transformer, but allow looking up a legitimate component defined in
map:components?
I'm still wanting to enable people (me!) to reuse action _code_ (not the
contract) with little re-coding of the original class file where not
necessary. If that can't be done in a clean way that doesn't invite abuse
then so be it, but I think it's worth trying for.
I just listed the solution without saying if I prefer it or not; basically
I don't know which is the best, but I tend to agree with Sylvain that
we should not build up a unnecessary wall. Ok, we could sheck for
SitemapModelComponent but I'm not sure if this is required.
SitemapModelComponent cannot help here, since those components
(generators and transformers, but not serializers) are managed by a
ComponentSelector. And this is this selector that will be looked up
through getComponent().
So the only way to forbid access to pipeline components (but again, does
it really make senses to use them in the flow ?) is to forbid access to
their selectors, through their respective roles (GeneratorSelector,
TransformerSelector, etc).
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [Flow] getComponent(id) implementation
Geoff Howard wrote:
At 12:27 PM 6/27/2003, Sylvain wrote:
Carsten Ziegeler wrote:
Geoff Howard wrote:
Do we want to force people to edit cocoon.xconf to call their own
business
components from the flow? I thought Stefano proposed checking for
SitemapModelComponent and disallowing it? Would that prevent
looking up
a transformer, but allow looking up a legitimate component defined in
map:components?
I'm still wanting to enable people (me!) to reuse action _code_
(not the
contract) with little re-coding of the original class file where not
necessary. If that can't be done in a clean way that doesn't
invite abuse
then so be it, but I think it's worth trying for.
I just listed the solution without saying if I prefer it or not;
basically
I don't know which is the best, but I tend to agree with Sylvain that
we should not build up a unnecessary wall. Ok, we could sheck for
SitemapModelComponent but I'm not sure if this is required.
SitemapModelComponent cannot help here, since those components
(generators and transformers, but not serializers) are managed by a
ComponentSelector. And this is this selector that will be looked up
through getComponent().
So the only way to forbid access to pipeline components (but again,
does it really make senses to use them in the flow ?) is to forbid
access to their selectors, through their respective roles
(GeneratorSelector, TransformerSelector, etc).
Aha - I dug into this the other night in looking into how you'd get a
sitemap component from the flow and had forgotten. So how about
denying access to the selectors for everything except actions? Are
the components from map:components available as normal through their
roles if we do that?
Yes, this is the solution : allow lookup of components only if they're
not in the forbidden list.
I guess the same answer there would apply to the global variables
declared in the sitemap?
BTW, the point as I understand it in restricting access to those
generators et al is to protect against abuse of people trying to
assemble pipelines from the flow.
Wow ! I really don't understand why someone would like to do that, when
calling a cocoon: pipeline defined by the sitemap is sooo easy.
Furthermore, it is currently possible to do it with Java code in e.g.
actions, and I never heard of someone crazy enough to do assemble
manually his own pipeline.
Anyway...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: Welcome the new ASF members
Stefano Mazzocchi wrote:
It is with real pleasure that I announce that three cocoon committers
were elected members of the ASF in the last round of votation that ended
today.
Vadim, Sylvain and Carsten (in alphabetical order by their last names)
Hoping that they will accept the invitation, I welcome them into the
higher level of ASF participation.
WOW, WOW, WOW and WOW !! What a pleasant surprise !
I am very honoured by this nomination, and heartedly thank those who
proposed me.
Member elections is a blind process for non-members, but I guess Stefano
must be for something in this ;-)
In 3 years using Cocoon (I started in july 2000), and 2 years of
committership (april 2001), I can say that Cocoon and Apache changed my
life. Cocoon is everywhere in my work (since july 2000, when it was
created, 95% of the projects made by my company are using it), and
allowed me to know a lot of people that were first names on mailing
lists, then friends on mailing lists, and now friends in real life and
business partners.
My actual involvement isn't always what I would like it to be (I need
some time for my wife and 2 sons and also for customer projects), but
the passion is there, both for the project and its community, and I can
assure you it will last.
Many thanks.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [SourceResolver] getLastModified() for cocoon:// sources alwaysreturns 0
Reinhard Pötz wrote:
If I call the method getLastModified() for cocoon://
sources the return value is always 0. Is this the
correct behaviour?
Yes !
If yes at least the JXTemplateGenerator (line 2868)
doesn't work correctly and I think some more components too.
Didn't look at it, but 2.1 components should rely on Excalibur Sources
and the associated SourceResolver (looked up in the component manager)
to use the Source's validity.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [RT] [Cocoon 2.2] Stacktraces in context
Bart Guijt wrote:
Hi all,
I am using Cocoon for almost a year now and if one thing bugs me, it is
this: if something fails to operate successfully, the Java stacktraces fail
most of the time to correctly show how the error occurred.
In Cocoon, we use sitemaps, XSL transformers, (additional) Java components
and URI resolving to get the job done. If something fails, we get a
(possibly very deep!) stacktrace from the SAX pipeline, a compiled XSLT
stylesheet, the appserver and the treeprocessor in no particular order, with
sometimes very misleading information.
What about a stacktrace like this:
Error foo bar occurred at:
Java: org.apache.cocoon.components.SomeComponent.Configure:237:4
Sitemap: /test/sitemap.xmap:25 (map:generate src=...
type=SomeComponent)
Sitemap: /test/sitemap.xmap:24 (map:match pattern=someresource)
Sitemap: /sitemap.xmap:20 (map:mount check-reload=yes src={1}/
uri-prefix={1} - {1}=test)
Sitemap: /sitemap.xmap:19 (map:match pattern=*/**)
URI: cocoon://test/someresource
XSLT: /xsl/foo-bar.xslt:454:53 (document())
XSLT: /xsl/foo-bar.xslt:25:10 (template: /)
Sitemap: /sitemap.xmap:30 (map:transform src=xsl/foo-bar.xslt)
Sitemap: /sitemap.xmap:28 (map:match pattern=page.html)
URI: page.html
The information provided is probably mentioned somewhere in the Cocoon logs,
but is scattered all over the place. The logs are a collection of events in
no particular order (multiple users) and are not traceable to a single
session. Even if you could trace these events leading to failure, it is a
PITA to figure out what the execution stacktrace actually was!
I don't know much about any Cocoon treeprocessor internals (Sylvain?), but
is such a thing possible? It would probably be a little difficult with the
XSLT part, but even then: Xalan fires trace events which are perfectly
suitable for this job.
So... how about it?
Yeah, error reporting isn't perfect in Cocoon :-/
For the treeprocessor, we have to distinguish the two phases of request
handling :
- pipeline building (matchers, selectors, actions) : this is under
control of the treeprocessor, which could log the location of the error
in the sitemap.
- pipeline execution (generator, transformer, serializer) : this is more
difficult because of the streamed nature of the processing.
Something which could help for both phases is to add the sitemap
statement location in the parameters. This would allow any component to
know the location of its invocation and reports it in its exception.
Exceptions raised in the second phase out of control of sitemap
components (e.g. in an XSLT processor) are much more difficult to
handle. We could have a special implementation of the pipeline that
shields each element of the pipeline by exception handlers that log the
error with its location (I whish we still had SAXConnectors...).
For the Cocoon 2.2 version of course!!
As this isn't disruptive, this can go in any version... once it's done !
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [RFI] Garbage
Pier Fumagalli wrote:
On 18/6/03 22:17, Peter Royal [EMAIL PROTECTED] wrote:
On Wednesday, June 18, 2003, at 01:34 PM, Pier Fumagalli wrote:
Concise question, concise answer:
Forget the XML syntax, use JXPath instead of JEXL for expressions...
Like:
document
#foreach $header in {request/headers}
#if {starts-with($header/name, 'X-'}
paragraph bold=true
#else
paragraph
#end
The header called quot;{$header/name}quot;
has value quot;{$header/value}quot;
/paragraph
#end
/document
ah, neat! :)
of course, why not use Jelly with JXPath as the EL?
From http://jakarta.apache.org/commons/jelly/
A Jelly script is an XML document which gets parsed into a Script.
From (myself)
Forget the XML syntax
Unless I'm not mistaken, the above example template is _NOT_ a well formed XML document! :-) :-)
Does this mean you wrote a parser to parse SAX-like events in a
non-well-formed XML document ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [vote results] FOM
Pier Fumagalli wrote:
On 17/6/03 22:51, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
- Should the flow _always_ be associated with a Session?
I haven't written a flowscript that didn't require, in some way or
another, the availability of some statefulness on data and it seems to
me as overkill to use full execution state preserving (and the
URI-encoding of the continuation every time!) just for the data
(besides, even today, if you want to keep global flow variables around,
you have to enable sessions anyway)
In general, it is true that continuations and sessions are different
beasts, but in real life, continuations *extend* sessions since they
provide the ability to save *even more* state than sessions.
But in those situations where procedular flow is weak and navigation
decisions are driven by user action and not by flow execution,
continuations are overkill and sessions are still the preferred way to go.
is there a real need for continuations without sessions? i really can't
provide a meaningful example of this.
so, I would say +1 to this.
if you are against this, please speak up now.
Pinching in at the last minute, as I'm completely overswamped by work at
this time (writing a template engine, u know, can be hard)...
We've got some _serious_ problems with sessions lately at VNU. The problem
we faced is that in 99.9% of the containers out there sessions, by
containers, are identified uniquely with a cookie stored on the client side.
What does that mean? That no matter how many browser windows you have open,
your client will uniquely be identified by the server as one.
Our problem lies in the multitasking ability of one client, so to say, to be
able to continue two instances of the same flow at once.
We have a registration centre, where people can mail (snail mail) and
phone in to subscribe for VNU's different magazine offering.
Let's take this example: one of our kids at the registration centre is
entering the details for one subscriber, whose information he got through
the post, she has a card in front of her, and goes through several web pages
(a some sort of flow) to enter (or rather copy) the user registration
card.
At the same point in time, the same person gets a call on the phone, he/she
needs to follow the SAME EXACT FLOW, but in a different instance (pausing
the card-based registration, and doing the same thing but asking the
details from the guy on the phone).
Now, if my flow is somehow stored in the session, which is stored in a
cookie, the card registration details, and the phone registration
details get messed up, as the server has no way to figure out that the same
client (identified by a cookie) is doing two instances of the same thing
at the same time.
We solved this by switching our servlet container to Jetty, which has a nice
feature forcing itself to completely ignore cookies and by URL-rewriting
every link and form action. By forcing this, we now have the opportunity to
have uniquely identified per-task based sessions (based on URL-rewrites),
rather than a global per-client session.
Given the current implementation of sessions on servlet containers, it's so
easy to F-word-UP is the client opens a new window and tries to do something
different (the client will either completely ZERO whatever task he/she is
doing, or mix up the session data), unless you don't force
URL-rewriting-with-cookie-ignoring (which AFAIK can be done only w/ Jetty).
Think about a continuation like an instance of a task stored on the
server, while unfortunately you have to realize that a session is the
instance of a client (with all its tasks) on the server.
Kinda like multiplexing, multiple tasks on the client, multiple tasks on the
server, only ONE and only ONE (in most cases) session between the client and
the server...
Just my 0.02 GBP/Euro/USD (depending on whatever country you're in)
Pier, unless I'm mistaken, it seems your problem can be solved with the
flow without hacking sessions.
A continuation tree is actually the flow instance you're talking
about. So you can have different flow instances running concurrently
smoothly, provided that their state is only stored in local variables.
Global variables should be used to represent state that is
user-dependent but not flow-dependent.
What do you think ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [vote results] FOM
Pier Fumagalli wrote:
Sylvain Wallez [EMAIL PROTECTED] wrote:
Pier, unless I'm mistaken, it seems your problem can be solved with the
flow without hacking sessions.
Indeed... But Stefano asked Should the flow _always_ be associated with a
Session?, which I assumed (maybe prematurely) as a one-to-one mapping
between session and flow, therefore reducing the number of flows in
execution by the client, as we have only one session...
Ah, I understand... that there's a misunderstanding here ;-)
The word flow in Stefano's quote actually means global variables of
flow scripts. But local variables of different instances of a flow
(i.e. the continuation trees started by a map:call function) are in
different spaces and don't conflict.
A continuation tree is actually the flow instance you're talking
about. So you can have different flow instances running concurrently
smoothly, provided that their state is only stored in local variables.
Global variables should be used to represent state that is
user-dependent but not flow-dependent.
What do you think ?
I'm fine w/ it, as long as the continuation ID is never stored in the session, but rather always URL encoded in the generated output...
That's the only thing I'm _really_ concerned about...
Some people asked in the past why continuations ID had to be transmitted
through URL rewriting or request params and couldn't be stored in
cookies. The answer was exactly about the problem you mention above : a
cookie, as the session, are unique for a given browser, and this is not
suitable to store a continuation id which identifies both a flow
instance and a location in that flow instance.
Hope this makes things clearer.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: Build failure
Olivier Billard wrote:
Salut Olivier ;-)
Is there any chance that it would come from my side ?
Does it works for you ?
Yep. Works fine here...
What's your config and do you have a local.build.properties ? Do you
build from command line or from an IDE ?
And more important, do you have a special version of Xerces in your
system classpath (best thing is to keep it empty) or the endorsed dir of
your JDK ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: Build failure
Olivier Billard wrote:
Salut Sylvain !
Seems that you won the jackpot !
A build from Eclipse doesn't work, but a build from command line works well.
But it didn't worked with an old CVS... I didn't tried the second time.
I think you're right : it may come from an other version of Xerces in
Eclipse... Damned ! But I don't have any endorsed folder in my jdk or jre,
and the other version of xerces is in another Eclipse project... It built
well some days ago ! If only I hadn't go in hollyday... (or hadn't come back
;) )
Golden rule number one : if something weird happens related to XML
handling (either parsing or XSLT), inspect (or suspect) the various
libraries that consitute the classpath ;-)
Cheers,
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [Flow] Scope and Sessions
Geissel, Adrian wrote:
Just a thought:
From a technical point of view, are there any other possiblities
of implementing the JavaScript global scope.
I assume this is a question. The request is obviously not good at this
and the servlet context is way too broad. Any other mechanism
would be a
data container associated in some way to the state of the webapp
execution and this is exactly what a session is.
Pier described a very good use-case which applies to pretty much every
real-world web application - that basically it is understood to re-entrant.
From my experience, storing state in the session has two issues - first is
the 'forked UI syndrome' described, and the second is that resources
associated with the state are held indefinitely, especially if the user
decides not to complete the operation, as is their choice.
My solution in the past has been to manage state / flow in the response (ie.
that sent back to the user), but obviously this is what Flow is trying to
improve.
So, my thought is this - can the flow state be included in the response for
re-submission later. For example, a flow-invoked HTML serializer could
insert hidden input fields to maintain state, or similar?
Mmmh... don't take it as an offense, but I think you missed what is
brought by continuations.
The global context, attached to the session, should be used to store
values that don't depend on the current interaction flow. These will be
mainly the user credentials, and any singleton values attached to the
user (can be a shopping cart for example).
Transient state, describing the current interaction with the user,
should be held by local variables in the flow function that drives this
interaction. This means that they're attached not to the session, but to
the continuation, and therefore can have different values if the UI is
forked.
So the flow state is transmitted through a single value, the
continuation identifier, which can be either in a hidden field or in the
submit URI.
Hope this helps.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: TreeProcessor:BUG
Klaus Bertram wrote:
Hi Joerg
yes I found it by debugging an action where the breakpoint was stoped
twice.
So I wrote a small test sidemap with an xsp side and database actions
By request the map:aggregation match, an action in map:part add a row
to the databse and then the xsp read the table entrys.
The browser show the insertred row, but the database had 2 new rows
The sitemap.log shows the complete match handling twice
After that I test the match form the part direkt with a request and it
works. (1 row added)
When needed I can send you my test sides.
Some questions to help us track the problem :
- do you use a caching pipeline ?
- if yes, does it still happen if you use a non-caching pipeline ?
- can you provide us the two stack trace when you hit the breakpoint ?
Thanks,
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [Flow] Scope and Sessions
Geissel, Adrian wrote:
snip/
So the flow state is transmitted through a single value, the
continuation identifier, which can be either in a hidden
field or in the
submit URI.
expressed class=so-much-betterThis is what I was trying to say
:)/expressed
By storing the continuation id (perhaps correlated with the session for
security - ie. a user has a session which may have one or more flows active)
as a hidden form parameter, it ensures that (re-)starting a flow does not
interrupt an existing one.
Exactly ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Linotype editing: browser requirements?
Gianugo Rabellino wrote:
snip/
BTW, Stefano: Linotype *really* kicks ass. Problem is that from you we
aren't expecting anything less, so this is why you are not getting all
the kudos you deserve. :-) But it's really, really, really a good job!
Yep. I just tried it for the first time. Edited a bit of text. Cool
(we're used to wysiwyg editig now). Clicked on the insert image button
and... wow !
And the big WOW : actually, the insert image button is useless. Just
drag'n drop an image from your file explorer in the text.
The last time I was so impressed by a web UI was with Xopus BitFlux.
Wonderful job. I will now open the box to look at what's inside. And I
expect more wows ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [Flow] Scope and Sessions
Marc Portier wrote:
Sylvain Wallez wrote:
Geissel, Adrian wrote:
Just a thought:
From a technical point of view, are there any other possiblities
of implementing the JavaScript global scope.
I assume this is a question. The request is obviously not good at this
and the servlet context is way too broad. Any other mechanism would
be a
data container associated in some way to the state of the webapp
execution and this is exactly what a session is.
Pier described a very good use-case which applies to pretty much every
real-world web application - that basically it is understood to
re-entrant.
From my experience, storing state in the session has two issues -
first is
the 'forked UI syndrome' described, and the second is that resources
associated with the state are held indefinitely, especially if the user
decides not to complete the operation, as is their choice.
My solution in the past has been to manage state / flow in the
response (ie.
that sent back to the user), but obviously this is what Flow is
trying to
improve.
So, my thought is this - can the flow state be included in the
response for
re-submission later. For example, a flow-invoked HTML serializer could
insert hidden input fields to maintain state, or similar?
Mmmh... don't take it as an offense, but I think you missed what is
brought by continuations.
might be the same over here, hope you can explain again since I'm
still failing to understand somewhat
The global context, attached to the session, should be used to store
with global context you mean?
guessing: variables declared in the flow javascript but put outside
functions?
Yep. Global context is the set of global variables (outside functions),
opposed to local variables (inside functions).
values that don't depend on the current interaction flow. These will
be mainly the user credentials, and any singleton values attached to
the user (can be a shopping cart for example).
Transient state, describing the current interaction with the user,
should be held by local variables in the flow function that drives this
but those are, if I got it right, not frozen inside the continuation,
but rather pointed to by reference?
Yep again. So if a variable created by a given continuation is modified
several continuations later and then you go back, the value is not
undoed, but keeps its modified value.
interaction. This means that they're attached not to the session, but
to the continuation, and therefore can have different values if the
UI is forked.
so with forking, I assume you mean the creation of a new
flow-interaction? (and not forking by opening another window in the
middle of a flow-scenario or branching the continuations with the
back-button-take-other-path)
Forking can mention both scenarios. In the case of a new
flow-interaction, there's no sharing of local variables. In the middle
of a flow scenario, variables declared before the fork will have their
values shared between continuations, while variables declared after will
have a different value in each branch. So yes, a local variable can be
shared between several continuation branches (fork within a flow
scenario). If this is not liked (because of the application specs), then
new variables should be created between the different creation of
continuations (i.e. between calls to sendPageAndWait).
So the flow state is transmitted through a single value, the
continuation identifier, which can be either in a hidden field or in
the submit URI.
so the different continuation identifiers of a certain interaction
scenario all point to
- their own execution-position in the flow-function
Yep.
- the same variables (and thus state?)
Variables defined within a continuation are shared by all its children,
but not its ancestors nor siblings.
and can additionally have access to the 'global space' which is
session and thus user-agent-tied?
Yep.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Cocoon 2.1 showstopper?
Nathaniel Alfred wrote:
Yes, it's only recompiling - nothing more (well, at least in
theory :) )
Carsten
For non-trivial Cocoon sites the 2.0.x to 2.1 migration will require
more than just recompiling component classes.
There are incompatibilities on different levels. The ones I am aware of
are:
1.) sitemap.xmap must add map:pipes in components definition.
2.) File upload class name changed from
o.a.c.components.request.multipart.FilePart to
o.a.c.servlet.multipart.Part.
3.) File upload method names changed from FilePart.getFilePath() to
Part.getUploadName().
(Need to confirm on this one. I don't have file upload working yet with
M2.)
4.) RequestGenerator changed namespace from
http://xml.apache.org/cocoon/requestgenerator/2.0 to
http://apache.org/cocoon/request/2.0.
5.) i18nTransformer changed namespace from
http://apache.org/cocoon/i18n/2.0 to http://apache.org/cocoon/i18n/2.1
I don't think it is worthwhile to attempt complete backwards
compatibilitity in 2.0 to 2.1. Instead there should be a Migration
Guide listing the known incompatibilities in a more comprehendable form
than the Changes file. Otherwise Cocoon users will be in for a rough
ride in the migration, possible producing a lot of bad press at this
crucial moment.
I think this is the way to go, as there are a number of small
incompatibilities that prohibit direct porting from 2.0 to 2.1 on
non-trivial sites, and ensuring strong back-compatibility seems difficult.
Furthermore, the mentioned byte-code incompatibility introduced by the
move to LogEnabled doesn't seem the most harmful to me, as a lot of
Cocoon apps don't define new components. Changes in built-in components
namespaces mentioned above are IMO much more confusing.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Cocoon 2.1 showstopper?
Carsten Ziegeler wrote:
Nicola Ken Barozzi wrote:
Well, there is a way out, but I don't know if we want to do it. It's
based on - ok, I'll say that word - an AOP interceptor mechanism(hehehe
a big wording for a simple concept).
snip/
Interesting idea - but does it work? Both interfaces Loggable and LogEnabled
declare the same method getLogger() (with the same arguments) but with
a different return type. How do you know which version is queried in
your invokation handler? (I have not done too much with Proxies so I might
be simply too blind ...)
Yep. I think proxies aren't the solution here, since we deal with
incompatible bytecode. We may, however, use a classloader that adapts
byte code on the fly. But this would be IMO too much hidden magic, and
it's better to invite people to recompile their code.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [Flow] Scope and Sessions
Reinhard Pötz wrote:
Today I tried to find out how sessions and flow work together:
1. If my tests are correct the global scope of a flow only
lives as long as the session which the flow is tied to is
active.
Once you have called cocoon.createSession(), this is true. Otherwise,
a new global scope is created for each request.
So if the session expires or you use another client to
continue a 'waiting' function you only have access to the
local scope within the flow function.
Yep.
2. All scripts within a map:script.../ part share the
same global context. If you want to share more objects
you need another scope (request, session, context).
Yep (AFAIK)
Is this description correct? If yes is this the intended behaviour?
Yes !
From a technical point of view, are there any other possiblities of implementing the JavaScript global scope.
Sure. Technically, all is possible !
If so has there ever been a community decision (vote) which of these possibilities is best?
I don't remember of a formal vote about associating the global scope to
sessions, but this seems very natural as the global scope can be thought
of as the permanent part of the application state, i.e. it is common to
the various functions contained in the script. And most often,
application state is tied to the user context which is the session.
I'm only asking because I'm curious - no offense to anybody!
Hey, asking is not offending ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [BUG]: Endless recursion in source resolving
Carsten Ziegeler wrote:
Carsten Ziegeler wrote:
After updating to the latest cvs I get an infinite loop in the
new portal demo:
http://localhost:/samples/portal/portal
I guess this is caused by the recent changes to the source
resolving.
Any clues?
It seems that the current implementation of the source resolver
is not very effective (thanks to Volker for the analysis :) ):
For each URI the absolutize() method is invoked, and this
uses the new regular expression to test the uri if it is
relative or not.
The implementation of the regular expression uses a very deep
stack that depends on the size (length) of the uri. In the
portal we have very huge uris (many request parameters appended)
and therefore the stack gets very deep creating the exception.
Now I see two simple improvements: a) don't use the regexp
on request parameters, which means search for a '?' and invoke
the regexp only on the part before the '?'.
b) A quick test if the uri is already absolute. If the URI
is already absolute we don't need the regexp test.
What about using the two ;-)
1/ test if the URI is absolute. For this, you can use Excalibur's
SourceUtil.getScheme() which performs a strict control on scheme syntax
without using a regexp.
2/ if not, use the regexp only on the part before the '?' (BTW, if '?'
is part of the URI, it should be encoded as %3F
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Cocoon Nuke
Bertrand Delacretaz wrote:
Le Samedi, 7 juin 2003, à 09:44 Europe/Zurich, Sylvain Wallez a écrit :
the code samples made my hair draw up on my head : hardcoded HTML
in Java code !!
Blessed arth thou, who haveth hair on their head ;-)
ROFL ;-)
It shows that users of such apps (simple CMSes) do not care what's
under the hood.
Sure, but module writers care about what's under the hood. And hardcoded
HTML means hard-to-write modules, and therefore no fancy features !
...Having this kind of application as a Cocoon sample would be a
killer to demonstrate its power. Furthermore, it may foster the
development of blocks.
Agreed but I would prefer such an app to be focused on / marketed as a
CMS development framework rather than a CMS app sample.
PHP-based light CMSes a la PHPNuke have the big advantage of being
very easy to install at most provider's sites: copy the .PHP files in
the right places, edit one of them for config, that's it. Java-based
apps cannot compete with PHP for ease of installation today unless
you're running your server.
OTOH a Cocoon-based CMS would be much better in terms of XML-based
content and expandability/connectivity through java, Avalon, etc.
So I think such a demo app should be clearly targeted as developers,
either to help them understand Cocoon or to serve as a basis for their
developments, but not at end-users who usually just want to quickly
setup a simple CMS and don't care about what's inside.
Mmmh... you're IMO both right and wrong. Right, because Java hosting is
microscopic compared to PHP hosting. But wrong since Cocoon is used
(from my personal experience) on many intranets, and having such
features builtin (as samples you can reuse) can certainly help Cocoon to
have a wider usage range, instead of installing a PHP Nuke on the httpd
that proxies Cocoon...
My 2 i18n key=favorite-currency/.
I guess it's swiss francs ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Cocoon Nuke
Hi all,
I just came across this article on ONJava : http://www.onjava.com/lpt/a/3904
The JBoss group has developped a so-called CMS based on the architecture
of PHP Nuke. In fact it seems more to me that it's an aggregation
framework with CMS-ish modules, and maybe some of the coplet state
management features. The article focuses on ease of deployment and
assembly of modules, but the code samples made my hair draw up on my
head : hardcoded HTML in Java code !!
Having this kind of application as a Cocoon sample would be a killer to
demonstrate its power. Furthermore, it may foster the development of blocks.
What do you think ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: cvs commit: cocoon-2.0/lib/core xalan-2.5.1.jar xercesImpl-2.4.0.jarxml-apis.jar xalan-2.3.1.jar xercesImpl-2.0.0.jar
Joerg Heinicke wrote:
Though we will get again endorsed lib problem questions on the users
list, I updated the XML lib jars to their latest releases as in Cocoon
2.1. I hope nobody has something against this. At least we have a good
explanation and solution for these issues now
(http://wiki.cocoondev.org/Wiki.jsp?page=EndorsedLibsProblem). If the
ParanoidCocooonServlet works ok only in Cocoon 2.1 a message shall be
added to this wiki page.
Actually, ParanoidCocoonServlet can be used to run *any* servlet. So
I'll commit the changes in the 2.0 CVS also, so that we can point users
to this page.
But there is another reason for this mail: Now with the current XSLTC
we can switch to it as default processor in 2.0 too, can't we?
And what about the using the treeprocessor as default in Cocoon 2.0?
If it's on the same status as in 2.1, it seems to be stable enough -
even for non-development/milestone releases.
Isn't it already the default ? The TreeProcessor has now been around for
more than a year...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Using Path expression in Map Action type
Geissel, Adrian wrote:
Hi Shane,
I've done something similar to what you're looking for with version 2.0
(don't know if it still works!):
Try:
map:act type='substitute(listOfMaps, {../1})'/
Note - single quotes are important (valid XML attribute definition - allows
the use of plain double-quotes!)
Wow, clever but *evil* hack : injection of Java code in the sitemap. As
Christian said : this will break as soon as you use the newest sitemap
engine (which is the only one available in 2.1).
The type attribute is static for every sitemap statement. This is a
design choice, as allowing dynamic types can quickly lead to
non-understadable and unmaintainable sitemaps.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: cvs commit: cocoon-2.0/lib/core xalan-2.5.1.jar xercesImpl-2.4.0.jarxml-apis.jar xalan-2.3.1.jar xercesImpl-2.0.0.jar
Sylvain Wallez wrote:
Joerg Heinicke wrote:
Though we will get again endorsed lib problem questions on the
users list, I updated the XML lib jars to their latest releases as in
Cocoon 2.1. I hope nobody has something against this. At least we
have a good explanation and solution for these issues now
(http://wiki.cocoondev.org/Wiki.jsp?page=EndorsedLibsProblem). If the
ParanoidCocooonServlet works ok only in Cocoon 2.1 a message shall be
added to this wiki page.
Actually, ParanoidCocoonServlet can be used to run *any* servlet. So
I'll commit the changes in the 2.0 CVS also, so that we can point
users to this page.
Done. I also added an optional servlet-class parameter, so that the
ParanoidCocoonServlet can be used to sandbox _any_ servlet.
But there is another reason for this mail: Now with the current XSLTC
we can switch to it as default processor in 2.0 too, can't we?
And what about the using the treeprocessor as default in Cocoon 2.0?
If it's on the same status as in 2.1, it seems to be stable enough -
even for non-development/milestone releases.
Isn't it already the default ? The TreeProcessor has now been around
for more than a year...
Yep. I checked and the TreeProcessor _is_ the default engine.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: cvs commit: cocoon-2.0/lib/core xalan-2.5.1.jar xercesImpl-2.4.0.jarxml-apis.jar xalan-2.3.1.jar xercesImpl-2.0.0.jar
Joerg Heinicke wrote:
Isn't it already the default ? The TreeProcessor has now been around
for more than a year...
Yep. I checked and the TreeProcessor _is_ the default engine.
searched for tree in 2.0 cocoon.xconf and didn't find it. after a
closer look I found it.
The TreeProcessor is the default class for the sitemap role. This is
why the class name doesn't appear explicitely in cocoon.xconf
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
The end of the infamous endorsed libs problem : ParanoidCocoonServletnow really paranoid
Hi all,
Short story : once again, I've hit the famous endorsed library problem.
So as usual I copied Cocoon's Xalan and Xerces to
tomcat/common/endorsed, but unfortunately this broke another application
that was running in the same Tomcat.
Damn. How to solve this ? Install another Tomcat ? Yeah, it will work,
but will add yet-another-JVM to the server, which I wanted to avoid. So,
I decided to use ParanoidCocoonServlet, and discovered that it was
actually not paranoid at all because it was not using the
ParanoidClassLoader it was supposed to use :-(
So I refactored a bit all our servlets and now ParanoidCocoonServlet is
_really_ paranoid. This means, that its classloader will _always_ try to
load classes and resources first from WEB-INF/lib and WEB-INF/classes,
ignoring any similar classes existing in the parent classloader. Xalan,
Xerces, etc are now really immune to whatever version of the same
library can exist either in the JDK or in the servlet engine.
Such a strong shielding can have some drawbacks, however : if a class is
given by the servlet engine (e.g. a JNDI context) and the same class
exists in the webapp libs (e.g. in jndi.jar), then you're very likely to
get a ClassCastException. This is likely to happen mostly with standard
APIs, and the solution is then to remove the offending library from your
WEB-INF/lib.
Enjoy,
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: C2.0.4: Strange XSLT behaviour in logicsheet when matching text() nodes (resent)
Ricardo Rocha wrote:
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...
Ah yes, I remember that, now. Gosh, the ancient times of Cocoon 1.x...
Thanks for refreshing our memory, Ricardo.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: The end of the infamous endorsed libs problem : ParanoidCocoonServletnow really paranoid
Bertrand Delacretaz wrote:
Le Mardi, 3 juin 2003, à 15:28 Europe/Zurich, Sylvain Wallez a écrit :
...Damn. How to solve this ? Install another Tomcat ? Yeah, it will
work, but will add yet-another-JVM to the server, which I wanted to
avoid. So, I decided to use ParanoidCocoonServlet, and discovered
that it was actually not paranoid at all because it was not using the
ParanoidClassLoader it was supposed to use :-(
Great, thanks! More signal, less noise ;-)
You've been wikified for posterity at
http://wiki.cocoondev.org/Wiki.jsp?page=EndorsedLibsProblem
Thanks Bertrand the wikifier !
However, I do not consider my initial post as some ultimate literature
that should go to posterity, and rewrote the whole thing with much more
details and explanations. I don't know if it's perfect, but at least
it's better ;-)
I also included some explanations for Geoff about the ClassCastException.
Comments updates welcome !
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: FOM and stateful components
Ricardo Rocha wrote:
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.
Agree, both with the anti-scripting look and difficult implementation.
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.
This won't work, since when a continuation path reaches the end of a
function, other paths in the same tree can still need these components.
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.
Again, the notion of use-case completion is intimately tied to the
various branches that exist on the continuation tree. Some use cases,
such as a shopping cart, will want to ensure that no other branch still
exists when the end of the function is reached (i.e. the order is
placed). To achieve this, the solution is to create a continuation at
the start of the function, and invalidate it when one of the branches
reaches the end of the function. The whole continuation tree is then
invalidated.
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?
I think there are only two reliable ways to manage stateful components :
1/ raise an error if there are some unreleased stateful components when
a continuation is created.
2/ tie releasing of a component to the death of the continuation to
which it belongs.
Solution 1/ solves the problem by suppressing its cause. Although it
seems very strict, we can also consider that application state should be
kept by script variables and and not state of components. This is
similar to your remark about EJB statefull session beans : keep state in
the webapp an not in the container.
Solution 2/ can answer transparently to your function policy. If the
whole continuation tree is invalidated at function completion on one of
the branches, all components looked up since the function started are
automatically released.
Although solution 2 seems nice, I still find it dangerous to allow
heavyweight resources to float around between requests. This is an open
door to many memory and performance problems if this feature is abused.
Also, it strongly prevents session serialization and thus the use of
flowscript on failsafe servers. So I would go for solution 1, which
enforces careful state management.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [Bug 20445] New: - i18n transformer does not recognize 2.0 namespace
Bruno Dumon wrote:
On Tue, 2003-06-03 at 23:12, Joerg Heinicke wrote:
I guess, legacy support won't be readded, so this is a WONTFIX?
yes, I agree. A bit of a problem though is that upon encountering the
old namespace, the I18nTransformer nicely logs a warning, however the
log level is error by default. Maybe we should lower it to warn instead?
(there are other components also logging deprecation warnings not
visible by default)
We should make a difference between deprecation (still works, but likely
to disappear in the future), and detection of abandoned features.
So IMO, if the old i18n namespace is detected but not supported, then
the message should be an error, since the feature is no longer provided.
But this leads to another question : why did we loose backwards
compatibility ? I'm a bit ignorant about the evolutions that led to
change the namespace, but why haven't we kept the old transformer beside
a new one handling the new namespace ?
This would have allowed a smooth migration path by not breaking existing
applications. Of course, the old transformer should log a deprecation
warning encouraging users to migrate to the new one.
So what about renaming the new transformer to I18nTransformer2 and
re-adding the old I18nTransformer ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Caching in cocoon, especially CIncludeTransformer
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
I don't like all those static methods that hardcode more and more logic,
and even less when they lookup some components...
Why aren't these methods part of a CocoonResolver component that would
extend Excalibur's SourceResolver with some XML-related features ?
You mean an extra component and not the Cocoon SourceResolver, right?
Ok, this could work and might be a cleaner solution. Agreed.
I don't know if this should be an independent component, or one that
extends the SourceResolver. But it would really be better to avoid too
much code in static methods. And even more code that performs some
component lookup under the scenes ;-)
Sylvain (having hard time to awake this morning ;-)
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Caching in cocoon, especially CIncludeTransformer
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
I don't know if this should be an independent component, or one that
extends the SourceResolver.
Ah ok, by independent component I meant a component that extends
perhaps the SourceResolver component from Avalon, but can still be
looked up using a component manager. So that it is available in
every component. This is in contrast to extending the Cocoon
environment.SourceResolver interface that is only available in
sitemap components.
Ah ok, I understand. Since Excalibur's SourceResolver than can be looked
up everywhere, I think we should strongly discourage the use of Cocoon's
legacy environment.SourceResolver, and consequently avoid enhancing it.
Having a new CocoonResolver extending Excalibur's SourceResolver seems
good to me.
But should this extended resolver be looked up with SourceResolver.ROLE,
or with a new CocoonResolver.ROLE ?
random-thought
This makes me think of a feature that would be good to have : component
aliasing.
Components that are not XML-related or that have no dependency on Cocoon
will lookup SourceResolver.ROLE, while Cocoon components that want to
use XML features will lookup CocoonResolver.ROLE.
Now, we will provide a single implementation for CocoonResolver and
hence (because of inheritance) SourceResolver. If two different roles
are used for the lookup, this normally means two different instances
(provided ths implementation iis ThreadSafe)
Now what if we were able to specify in cocoon.xconf that
SourceResolver.ROLE is just an alias for CocoonResolver.ROLE ? We would
have a single instance for two different roles.
The same could be used e.g. for InputOutputModules : we could have a
single e.g. SessionAttributeIOModule implementing both InputModule and
OutputModule, and have the 'session-attr' input-module configuration be
an alias for the 'session-attr' output-module.
/random-thought
Sylvain (now awaken, stimulated by these wild thoughts ;-)
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: C2.0.4: Strange XSLT behaviour in logicsheet when matching text() nodes (resent)
Geissel, Adrian wrote:
Silly mail client!
Hi all,
I building an XSP Java logicsheet, and use the following constructs:
xsl:template match=* mode=ctrl-mode
xsp:logic
xsl:apply-templates select=@* mode=ctrl-mode/
this.contentHandler.startElement(
xsl:value-of select=namespace-uri(.)/,
xsl:value-of select=local-name(.)/,
xsl:value-of select=name(.)/,
xspAttr);
xspAttr.clear();
xsl:apply-templates select=text()|* mode=ctrl-mode/
this.contentHandler.endElement(
xsl:value-of select=namespace-uri(.)/,
xsl:value-of select=local-name(.)/,
xsl:value-of select=name(.)/);
/xsp:logic
/xsl:template
xsl:template match=text() mode=ctrl-mode
xsp:logic
// snip...
/xsp:logic
/xsl:template
xsl:template match=@* mode=ctrl-mode
!-- Filter out namespace declaration attributes --
xsp:logic
tempValue=xsl:value-of select=./;
// snip...
xspAttr.addAttribute(
xsl:value-of select=namespace-uri(.)/,
xsl:value-of select=local-name(.)/,
xsl:value-of select=name(.)/,
CDATA,
tempValue
);
/xsp:logic
/xsl:template
What I am observing is that the text() nodes are never
matched, even thought the source file clearly includes text
in the nested elements. Nested elements and attributes are
processed as expected.
Has anyone else come across this?
Envronment is standard Cocoon 2.0.4 release running on WL7.0 on Windows NT4
SP6.
IIRC (but don't ask me why), the XSP engine wraps every text node from
the XSP file into xsp:text elements.
So you may want to match xsp:text and not text().
Hope this helps,
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Caching in cocoon, especially CIncludeTransformer
Torsten Knodt wrote:
On Sunday 01 June 2003 15:47, Carsten Ziegeler wrote:
CZ There is already such a component, the cinclude transformer uses this
CZ for the caching. It should be easy to use that component in the
CZ xinclude transformer as well.
Please, add a blank line before the reply, this will make reading easier.
Yes, I know. But it'S still to much coding for it in the CIncludeTransformer. Components which need the content of a source, should simply get it, and not think about caching. It's not their job. Caching is needed in to many places. All places which use sources, should have caching. It should only be done at one place for each kind of data.
As Carsten, I don't agree with this : caching must be optional, and is
not useful in every place.
Take for example the XSLTProcessor : caching the source content from
which the stylesheet was read is useless, since we keep in the store the
corresponding pre-analyzed Templates object. The _validity_ of the
source is important to know if the stylesheet has changed, but caching
the stylesheet as DOM or SAX events is just waste of memory.
Another example are the cocoon: sources for which caching the source
is _always_ useless :
- either the called pipeline is cacheable in which case its contents is
stored in the Cocoon cache,
- either the called pipeline is not cacheable, and then caching the
source result is also useless, since this content will always be invalid.
So what I suggest is introducing SourceUtil.getInputStream for InputStream's of sources. Then modify toDOM and toSAX to cache their output, to not have them to parse them first out of the cached InputStream's. So we would cache InputStream's, DOM's and SAX streams. The only changes in the components would be to use SourceUtil, where they currently use their own code.
I don't like all those static methods that hardcode more and more logic,
and even less when they lookup some components...
Why aren't these methods part of a CocoonResolver component that would
extend Excalibur's SourceResolver with some XML-related features ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] FOM
Stefano Mazzocchi wrote: on 5/27/03 4:06 AM Sylvain Wallez wrote: Object getComponent(id) - obtains the component indicated by the given ID Why don't you use the traditional lookup() name ? Also, release() is missing. So what about lookupComponent(id) and releaseComponent(id)? release() is missing on purpose. It follows the same principle of malloc considered harmful that Java uses for garbage collection. [and the principle that Avalon 5 is supposed to use] as for changing the name from get to lookup I'm neutral on this. An important question, also : how does component management fit with continuations ? if you store your component in a variable, that instance is kept into the continuation object. Can a component be frozen by a continuation and unfrozen in a different environment ? it's not the component that is frozen into the continuation, but it's instance. a continuation cannot freeze the state of a java component. Ok. By component, I actually meant instance obtained by lookup() or getComponent(). Then we have a big problem here : automatic component release is very likely to be handled by the container at special times such as end of request processing. This means the continuation will use released components, thus eventually leading to concurrent access problems since the container is likely to have given the instance to someone else through another lookup(). On the other hand, explicit release like we have today means that the continuation becomes heavyweight since it keeps references to instances that may have been taken out of a pool. And even worse, if a continuation is abandoned we have some leaks since the instance is never released. Mmmh... A solution may be to use the catch(break)/catch(continue) to release components when a continuation is created, and control this at creation time, raising an error if there are still some unreleased components. This should do the job, at the price of important constraints for the flowscript writer. We could have some hooks that automatically relase components when a continuation is frozen, but then what about stateful components ? Ricardo told me that the EJB community has already discussed these issues extensively (not for continuations, but for stateful components). Ricardo, anything to add here? Yes, please. snip/ WARNING: removing load() does *NOT* imply that you have to force all your flow in one big file. The way to fragment your flow into different files is to use several map:script elements in the map:flow section of the sitemap. Load support is IMO required because JS lacks an import statement. Not having it means we'll have to write a map:script for the script we want to use, but also for *all the scripts it depends on*, recursively. This will be very difficult to manage. Hmmm, I see your point, but let me point something out. In the future, I foresee something like map:flow map:script src=block:whatever:/flow/flow.js/ map:script src=cocoon:/myDynamicFlow.js/ map:script src=myStaticFlow.js/ /map:flow since we agreed that blocks only expose a URI space controlled by the sitemap (they don't expose resources directly!) you can use a reader to get the flow to the dependent block, or you can use a pipeline to generate your flow (for example, traducing a workflow written using a markup language into the equivalent flow instructions). Here you have all the machinery you need to compose your flows as you like. Recursively. The difference between the above and load() is thin but real: while load() has to be executed at runtime, the map:script calls can be done at sitemap assembly time. It could have a big impact on runtime performance of the flowscripts. Mmmh... what you're stating here is that we can have families of flowscripts (I was about to write classes) whose contract is defined by the toplevel functions (and hence object classes) they provide, and that a sitemap will assemble its flow script by loading an instance of each of the required families. So through it's URI contract, a block will provide not only XML processing services, but also flow code. That's interesting... --- properties - cocoon.request - the request object cocoon.response - the response object cocoon.log - the log object NOTE: the absence of the context object is intentional! we couldn't come up with a reasonable need for such an object at the flow level. So, for the principle of 'less is more', we don't consider it. Be aware that if you want to propose its addition, you have to come up with a reason for it. A simple reason : the context object (the environment one) gives access to context parameters defined in web.xml. In many situations, this is where parameters depending on the deployment environment are located, as it allows the sysadmin to use it's favorite app server GUI to set them and avoids editing cocoon.xconf. (yes, I've seen some installs being totally screwed up
Re: [RT] FOM
Stefano Mazzocchi wrote:
on 5/27/03 1:44 AM Stefano Mazzocchi wrote:
Pier and I already stated a while back that our current implementation of the FOM is weak and its design poor.
In the past, it was exactly such comments that made Ovidiu abandon this
community.
Let me state things clearly so that we can clear the sky even on this:
Ovidiu, please excuse me for copying you on this, but I would like to
let you and everybody else know this:
Stefano, seems like you were too fast at sending and forgot to CC Ovidiu...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] FOM
Stefano Mazzocchi wrote:
on 5/27/03 2:33 AM Bertrand Delacretaz wrote:
snips cause=agree or dont't understand implications enough to talk/
Le Mardi, 27 mai 2003, à 08:44 Europe/Zurich, Stefano Mazzocchi a écrit :
... 2) design for safety: the flow will be a center of abuse because people will find it easier to write longer flows than to restructure their business logic into components. We must make all possible efforts to reduce this from happening
+1.
This is very important so that Flow does not become the next JSP or ASP
;-)
... Object getComponent(id) - obtains the component indicated by the
given ID...
Does this mean *any* Component, or do you foresee a way for Components
to say if they're made available in the FOM or not? Making everything
accessible might also lead to easy abuse IMHO.
This is another concern entirely. We are currently focusing on the FOM,
that is, on the contracts between the two layers.
Obviously, the flow will not have access to *all* components, but only
to components that will be flow-available.
Ah, here's the reason of my misunderstanding about components. But how
will we decide which will be the good components that will be
flow-available ?
On the subject of abuse : flowscript is a perfect tool for RAD. Setting
up a demo in hours instead of days with some abusing flowscript is a
real bonus when you have to convince a customer. So constraining it too
much may kill a important benefit of Cocoon compared to other frameworks
when it comes to use it to gain a project.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Regarding Excalibur XMLUtil and Store
Stefano Mazzocchi wrote:
As a sidenote, I managed to infect Ricardo back with all the memes about
flow, blocks, DHTML, mozilla, software darwinism and more. He's so
excited that he can't even sleep at night (I'm serious!). Knowing him, I
wouldn't be surprised if I wake up tomorrow and he wrote the whole block
architecture and deployment manager :-)
What is Ricardo doing now ? He's been away for such a long time... Is he
still using Cocoon and following what's going on here ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [Fwd: [heads-up] Updated upload system and fixed a bunch of securityissues]
Stefano Mazzocchi wrote:
snip/
Note that the Cocoon Environment Request object transparently wraps
around the Object get(String name) method, so, you don't have to do
any type casting since this is transparently done for you.
The only difference is that since the Cocoon Environment doesn't
specify the *input part* object (this is something we'll have to do in
the future), the type casting is required to acquire the input part
that wraps around the uploaded file.
What's the real contract behind Object get(String) ? The method name
isn't very meaninful and the JavaDoc is confusing, as it is identical to
the one for getAttribute(), although the implementation is obviously
different.
Furthermore, is get() useful for something other than file upload ? If
not, why don't we define Object getMultipartPart(String) and
remove/deprecate this method ?
We could even add this InputPart you're talking about to the
enviromnent, inspired by o.a.c.c.request.multipart.FilePart.
Thoughts ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [Fwd: [heads-up] Updated upload system and fixed a bunch of securityissues]
Stefano Mazzocchi wrote:
Sylvain Wallez wrote:
What's the real contract behind Object get(String) ? The method
name isn't very meaninful and the JavaDoc is confusing, as it is
identical to the one for getAttribute(), although the implementation
is obviously different.
Furthermore, is get() useful for something other than file upload ?
If not, why don't we define Object getMultipartPart(String) and
remove/deprecate this method ?
MultipartHttpServletRequest is never accessed directly, so this
contract isn't really meaningful.
The *real* contract is o.a.c.environment.Request which already contains
object get(name);
and this should be changed to something more meaningful, but this
requires much more thinking also to think about mail processing.
I understand, but (again) what's the purpose of this get(), which is
obviously not what is said by its Javadoc ?
We could even add this InputPart you're talking about to the
enviromnent, inspired by o.a.c.c.request.multipart.FilePart.
yes, but I didn't want to mess with the environment right before the
release.
Ok. We also have to consider (just had this idea) that uploaded parts
don't make sense only in the servlet environment : in a mailet
environment, this could also be used for email attachments.
BTW, I remember someone (was it Nicola Ken ?) saying it was working on
such a mailet environment. Any news ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [GUMP] Build Failure - Cocoon
[EMAIL PROTECTED] wrote:
snip/
/home/rubys/jakarta/cocoon-2.1/src/java/org/apache/cocoon/selection/ExceptionSelector.java:61: package org.apache.commons.lang.exception does not exist
[javac] import org.apache.commons.lang.exception.ExceptionUtils;
[javac] ^
[javac] /home/rubys/jakarta/cocoon-2.1/src/java/org/apache/cocoon/selection/ExceptionSelector.java:163: cannot resolve symbol
[javac] symbol : variable ExceptionUtils
[javac] location: class org.apache.cocoon.selection.ExceptionSelector
[javac] Throwable cause = ExceptionUtils.getCause(thr);
[javac] ^
[javac] 2 errors
BUILD FAILED
/home/rubys/jakarta/cocoon-2.1/src/targets/compile-build.xml:44: Compile failed; see
the compiler error output for details.
Total time: 22 seconds
My bad : I forgot to update gump.xml.
It's fixed now.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Generators now allowed in map:handle-errors
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
However, allowing a generator in map:handle-errors is incompatible
with the current syntax.
The idea was to allow it and make it *optional*. I.e., if no generator
specified - use noifier, if user specified some generator - use it
instead of default. As you see, syntax here is fully compatible.
Nicola Ken Barozzi wrote:
Sylvain Wallez wrote, On 01/04/2003 23.35:
Hi team,
I finally implemented the very old todo about allowing generators in
map:handle-errors (see [1]).
Thanks man, very much appreciated :-)
But isn't it possible to keep compatibility by inserting the
NotifyingGenerator when there is no Generator?
The compatibility is ensured by specifying a 'type' attribute, whose
presence triggers the addition of the implicit NotifyingGenerator.
I prefer the user to explicitely specify which type of error handling is
wanted (2.0 or 2.1 mode) rather than having a generator automagically
added. This will prevent difficult bugs in sitemaps that may occur when
the user wants 2.1 mode but forgot a map:generate or if the
matcher/action path doesn't include one.
Now from an implementation point of view, finding if a generator is
present by analyzing the sitemap is difficult, if not impossible, since
a generator can be inside a matcher/action/selector (will we go in that
path or not ?), or included in a resource also used in the normal
pipeline. Also, checking this at request processing time is difficult,
since the pipeline fails if a transformer is added when no generator is
present.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [ANN] New version of XMLForm released
Stefano Mazzocchi wrote:
snip/
During the last year of consultancies, I found out that several people
identified XMLForm as the possible way to turn cocoon into better
webapp-capable system.
And having a good form-handling package in Cocoon is absolutely
necessary to have it adopted to build web applications. I can't remember
how many people asked me about Struts vs Cocoon. I know they are not
comparable, but these people were actually asking for a good forms
handling package.
And web applications are key for Cocoon's future, since even
publication-oriented sites now want CMS functions that are basically web
applications.
snip/
and include all that 'somewhat-business-logic' that is so common
between webapps that should be factored out and provided directly by
cocoon (as struts, somewhat, does).
And we should as far as possible build on some common mechanisms such as
commons-validator that will both factorize development effort, promote
cross-project pollinization and help people migrate from JSP/Struts
environments to Cocoon.
But I'm more than happy to see XMLForm being factored out because:
1) this removes the wrong marketing perception that XMLForm is *the*
solution for data-logic control.
2) allows people to experiment different approaches (XForm-based or
not) with the same level of confidence.
FormValidationAction did not prevent XMLForm nor Precept to appear, but
these are good arguments to ensure further innovation and development in
this area. And, BTW, Precept is already a block.
So +1 for a block, but I'm still wanting the current XMLForm code base
to stay in Cocoon's CVS.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [ANN] New version of XMLForm released
Nicola Ken Barozzi wrote:
Stefano Mazzocchi wrote, On 02/04/2003 12.47:
...
But I'm more than happy to see XMLForm being factored out because:
1) this removes the wrong marketing perception that XMLForm is *the*
solution for data-logic control.
2) allows people to experiment different approaches (XForm-based or
not) with the same level of confidence.
Comments?
I held back my comments till now because there was some negative
energy going round, especially because of the way it was proposed,
but IMO factoring XMLForm out of Cocoon as a library to process XForms
makes perfect techniological sense, both for Cocoon (as you nicely put
it) and for XMLForm, as it would be usable like the Struts Validator
is for example.
Does it so much make sense ? The main difference of XForms with other
traditonal forms is the client-side markup and this is where Cocoon
shines by allowing XForms markup to be translated to regular HTML until
browsers natively support it. A server-side implementation will mostly
concentrate on form validation, which is common to every webapp
framework, be it XForms-based or not.
So IMO an Cocoon-independent solution will be mainly a form validation
package, or it will have to reinvent some of the Cocoon mechanisms.
I think though that this can grow into an Apache (sub)project. What
would you suggest in this case?
Mmmh... Don't be too fast : let's wait and see how it evolves and what
community will be around it...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] Towards a new/another Forms Framework
Bruno Dumon wrote:
The last few days I've been doing some thinking about form-handling.
I've been looking at the current solutions in Cocoon and IMHO there
still is room for improvement here and there. BTW, all this has nothing
to do with Ivelin's announcements, or with the fact that it's April 1
today. It's been stuff which has been brewing in our heads for quite
some time.
I'm not going to write a long proposal here (or at least I'll try not
to), but just some notes to make clear in what direction I'm thinking.
Since everybody is throwing ideas here in a somehow unordered way, let
me throw in mine, considering my experience with our home-grown forms
framework that we use since late 2000.
First of all, we use a model to define entities, which can be either a
business object or a form. An entity defined by a set of fields, each
field having a type. A field can also be a relation to some other entity
(more on this later). This model is more like XMI than like XMLSchema.
On this model, we have different families of mappings : forms mapping,
persistence mapping (to store e.g. in a database), javabean mapping
(relation to the object model), etc.
The form mapping, and IMO this is where XMLForm has strong weaknesses,
defines formats for either datatypes (int, date, etc). or each of the
fields. We also make a difference between input and output formats. A
date for example, can be displayed as Wednesday 2 april 2003 but input
as 04-2-2003 on the same screen. Formats can also be i18n-ized,
meaning the previous example on a french browser will be displayed as
Mercredi 3 avril 2003 and input as 2/4/2003.
Since fields can also be defined as relation to other entities, we can
use this information to automatically populate pop-menus and lists. This
is a little bit like the beaff.enumeration in Bertrand's proposal.
Once we have an entity model an some associated formats, we can feed a
view with it. The view contains some widgets related to either a
datatype or a particular field. This allows for example to have any
input associated to a date field automatically converted to an input
with a fancy calendar popup and some client-side syntactic validation;
When the form is submitted, the server-side validation framework parses
each input with the format defined in the mapping, and feeds the data
model, reporting any violation.
Now back to the discussion.
In the above, the important features that are currently missing in
XMLForm are mainly the ability to define the input/outpout format for
non-trivial datatypes such as dates.
Also, we must be able to define a forms model through a configuration
file, avoiding the need to write Java code for simple cases. DynaBeans
are IMO a good solution for this, and are becoming the de-facto standard
for dynamically typed objects at least in the Apache-Java world.
Next, I would like Cocoon's form solution to be based on existing
components. Form validation is a sooo common problem that we should
avoid as far as possible to reinvent the wheel and concentrate on the
Cocoon-specific part of form handling, which IMO is mainly in the view
area : form population, widgets, etc.
A good candidate seems to be commons-validator : a lot of work is going
on there, and joining forces will lead to a more featureful package than
if we do our own. Also, as I stated in a previous post, this promotes
cross-project collaboration and will ease the migration of users between
the various Apache frameworks. And this can only be good for Cocoon.
Ah, and special thanks to Stephen Burns for his version of XMLForm based
on commons-validator. This definitely has go in our code base.
Thoughts ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Is build jetty-standlone needed?
Pier Fumagalli wrote:
Bertrand Delacretaz [EMAIL PROTECTED] wrote:
Correct me if I'm wrong but I think there is currently no easy way to
deploy a Jetty + cocoon system by just copying files created by the
cocoon build.
And there should not. The Jetty version included in Cocoon is _not_ the full
version. If you want to build your own Jetty + Cocoon distro, download
Cocoon, dowload Jetty, build the webapp, and deploy it using the
documentation supplied by Jetty
Although I am a big fan of it, and use Jetty in production everywhere I can,
it would be counter-productive for this community to elect one as a engine
of choice, and promote it against other...
I guess Bertrand's purpose is not to use it on production servers, but
to have a small standalone server that can be used for e.g. demonstrations.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Generators now allowed in map:handle-errors
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
snip/
Now from an implementation point of view, finding if a generator is
present by analyzing the sitemap is difficult, if not impossible,
since a generator can be inside a matcher/action/selector (will we go
in that path or not ?), or included in a resource also used in the
normal pipeline. Also, checking this at request processing time is
difficult, since the pipeline fails if a transformer is added when no
generator is present.
AFAIR, in my version of the implementation of this feature (don't ask
what happend to this implementation :-/ ), the way to solve it was to
extended and/or modify pipeline implementation so it uses default
generator when no generator has been set. This extended / modified
pipeline implementation can be instantiated from the error handler
node of the treeprocessor, and provided with default generator
notifier.
Ah, I understand. Clever solution.
But once again, I prefer to avoid automagic implicit behaviour of the
sitemap engine, and encourage people to migrate to writing a
map:generate in their error handling and consider implicit generator
and 'type' attributes on handle-error as deprecated features.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
[proposal] deprecation logger
Hi folks,
We have in the 2.1 a number of features that are considered as
deprecated, although still supported. We need a way to inform users (the
ones that write Cocoon apps) that they use such deprecated features in a
way that allows them to be found easily, and not intermixed in the usual
logging flood.
So I'm thinking about a global logger dedicated to deprecation messages.
This would allow to write all messages going to that logger to e.g. a
deprecated.log file.
Now how do we make this logger accessible ? A static variable doesn't
seem to be a good solution, so I'm thinking of adding it to the Avalon
context. Any Contextualizable component can then access it.
Thoughts ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] the quest for the perfect template language
Stefano Mazzocchi wrote:
The more I use the flow inside cocoon, the more I think there is no
way back. Not only it enforces SoC, it also removes over-SoC, which
happens where you have your information scattered around the entire
place (as for PHP stuff, for example).
But if the sitemap is the ultimate pipeline engine and the flow is the
ultimate (and transparently statefull!) controller engine, what is the
*ultimate* view, the best template system?
snip/
Optimize code that will run on so many different execution
environments is very hard, if not impossible.
The only interesting approach, IMO, is the one taken by XSLTC:
compiling the stylesheet doesn't necessarely mean to *inline* the
execution of methods by unrolling loops (like it is done in XSP, for
example), but to remove those checks that are not necessary because
the stylesheet has been analyzed previously.
This exactly the approach taken in the treeprocessor, that led it to be
a few % faster than the compiled engine.
This is nothing different from what hotspot does, only that it does it
with run-time collected information.
So, the point is: compilation is useful only if its used to remove
operations that are not going to be needed.
- o -
Here are my thoughts:
1) I've come to the conclusion that we need both generation-based and
transformation-based approaches.
Why?
well, the first is useful when you have non-xml data fed into the
view, the second is useful when you have xml data fed into the view.
With the ability of cocoon pipelines, it's going to be harder and
harder to choose which approach is best as I find myself using *both*
at the same time in different situations.
2) stream based solutions are better than non-stream based one because
they *always* remove the parsing stage.
3) all template languages will need
a) variable expansion
b) conditionals
c) iterations
and nothing more!
4) verbosity of the syntax must be balanced: too few verbosity is
efficient but grows into obscurity (ie Perl), too much verbosity is
harmful because signal/noise ratio is reduced.
5) control should be inverted: the template must be a view, it should
be 'pushed' the data in, it should not contain any data-pulling logic
other than the one used to pull data from the dataset passed on by the
underlying controlling stage.
Some restrictions on the push model : it requires the pushed data to be
fetched by the flow before being processed by the view. Although this is
fine in most simple cases, there are some applications where large
datasets are used to build the view, and SAX-based streaming really is
necessary (e.g. database extraction).
In that case, we must have an hybrid model where the flow pushed
information that allows the view to pull its content. E.g. the flow will
push the parameters of a SQL query which is executed by the view and has
its result streamed.
- o -
IMHO, the template language which is closer to the optimum is XSLT but
only with one change:
FORGET THE XML SYNTAX!
I'm entering wild mode now, so bear with me. Suppose you had:
1) a syntax that is simple and efficient to describe a stylesheet
2) a defined object model accessible thru regular xpath queries
I guess you mean that flow context is made available to the stylesheet
through XPath-enabled variables, right ?
3) no ability to call extensions
It's s useful to call some helper Java classes in XSLT to overcome
the limitations of XPath...
snip/
then we can have the following templatesheet:
namespace (ns) {
http://whatever;
}
template (/) {
html
head
title{list/@name}/title
snip/
unknown language \ [EMAIL PROTECTED] \
}
/td
/tr
}
the above should be parsed, transformed into a regular xslt stylesheet
and fed into a normal XSLT processor with extensions.
snip/
What do you think?
You reinvented XSLScript ! It's at http://www.pault.com/pault/prod/XSLScript
Ah, and how does this fit with caching ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [proposal] deprecation logger
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Hi folks,
We have in the 2.1 a number of features that are considered as
deprecated, although still supported. We need a way to inform users
(the ones that write Cocoon apps) that they use such deprecated
features in a way that allows them to be found easily, and not
intermixed in the usual logging flood.
So I'm thinking about a global logger dedicated to deprecation
messages. This would allow to write all messages going to that logger
to e.g. a deprecated.log file.
Now how do we make this logger accessible ? A static variable doesn't
seem to be a good solution, so I'm thinking of adding it to the
Avalon context. Any Contextualizable component can then access it.
Thoughts ?
Nice suggestion; but can't we just use WARN for deprecation warnings?
In above-then-debug log setting these messages will be well noticable.
Well, this is effectively much more simple ;-)
But don't you think a special category getting all deprecation warnings
could be useful ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] the quest for the perfect template language
Steven Noels wrote:
On 2/04/2003 20:25 Stefano Mazzocchi wrote:
IMHO, the template language which is closer to the optimum is XSLT
but only with one change:
FORGET THE XML SYNTAX!
Corollary, we should drop the XML syntax for the sitemap. I
customarily use this syntax when RT'ing snippets:
match pattern=foo
generate src=baa.xml
transform src=too.xsl
serialize
I admit having read many Python books lately.
We can easily guess that. Please, please add braces !!!
match pattern=foo {
generate src=baa.xml
transform src=too.xsl
serialize
}
;-P
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [ANN] New version of XMLForm released
ivelin wrote:
The new standalone version brings up to date the UI Form control syntax to
match the latest XForms Candidate Release.
Should we bring the Cocoon version up to date as well?
The propsed plan is to replace the current module with an Action/Transformer
adapter pair that references the standalone library.
Please vote.
Cocoon's XMLForm, even if driven by you, is a community effort. What you
propose here is to remove these source files in favor of a forked
version developped by a closed community (a one-person community, to be
precise).
This means XMLForm will be out of control of the Cocoon community, so :
-1
However, if you want to provide integration of your fork with the Cocoon
code base, you can create a new block dedicated to this, that should not
interfere with Cocoon's XMLForm.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [OT] Porting Cocoon to the Whitespace language?
Geoff Howard wrote:
At 06:34 AM 4/1/2003, you wrote:
Bertrand Delacretaz wrote:
Le Mardi, 1 avr 2003, à 13:19 Europe/Zurich, Diana Shannon a écrit :
...Do other countries besides the US celebrate a pranks/joke day
like today, April 1? Or are we the only fools? ;-)
AFAIK it happens everywhere in Western Europe, but I might be wrong?
I don't know about other countries.
In France, we call this kind of jokes an April fish. Children also
pin paper-fishes in the back of people.
Comment dit-on April fish en Francais?
Poisson d'avril !!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Generators now allowed in map:handle-errors
Hi team,
I finally implemented the very old todo about allowing generators in
map:handle-errors (see [1]). This means that you are no more forced to
have an initial XML document representing the error, but you can instead
build a regular pipeline with whatever generator you want.
I also have added a new ExceptionSelector that allows to easily drive
the construction of the error pipeline depending on the actual error
that occured (see examples below).
However, allowing a generator in map:handle-errors is incompatible
with the current syntax. So, the choice between with/without implicit
generator is driven by the presence of the type attribute on
map:handle-errors :
- if there is a type attribute (which can have the values 404 or 500),
the old implicit generator behaviour is used,
- if there is no type attribute, the new behaviour is used, and there
must be an explicit generator.
This second item may break existing sitemaps. The solution is to simply
add a type=500 attribute to obtain the old behaviour (the 'type'
attribute, an old-time hack, is now deprecated).
The sitemap engine takes care of issuing meaningful error messages if
the error-handling pipeline is not correctly build, to ensure users
won't get stuck with strange messages caused by this compatibility
problem. The message is as follows :
Incomplete pipeline : 'handle-error' without a 'type' must include a
generator, at sitemap.xmap:134:67
Either add a generator (preferred) or a type='500' attribute
(deprecated) on 'handle-errors'
Here's how error-handling in the main sitemap now looks like :
map:handle-errors
map:select type=exception
map:when test=not-found
map:generate src=not-found.xml/
map:transform src=welcome.xslt/
/map:when
map:otherwise
map:generate type=notifying/
map:transform src=stylesheets/system/error2html.xslt
map:parameter name=contextPath value={request:contextPath}/
/map:transform
/map:otherwise
/map:select
map:serialize/
map:handle-errors
This means that when we have a not-found type of error, we display a
static document, while other errors are handled the usual way, now using
explicitely the notifying generator to start the pipeline.
The ExceptionSelector is configured as follows in the main sitemap :
map:selector logger=sitemap.selector.exception
name=exception
src=org.apache.cocoon.selection.ExceptionSelector
exception name=not-found
class=org.apache.cocoon.ResourceNotFoundException/
!-- The statement below tells the selector to unroll as much
exceptions as possible --
exception class=java.lang.Throwable unroll=true/
/map:selector
This allows to :
- associate symbolic names to one (or more) exception class names
- define which exceptions should be unrolled, meaning their cascaded
exception, if any, is taken into account to find the symbolic name. This
allows match the actual exceptions that caused the error even if they
were rethrown embedded in a higher-level exception.
This configuration is processed top-down up to the first matching
exception, meaning that, just as in a Java catch clause, most specific
classes must come first (the selector checks this).
Enjoy,
Sylvain
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=102637618202439w=2
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Source and commons-vfs
Gianugo Rabellino wrote:
This is probably more an Avalon questions, but since it seems that
Cocoon is the heaviest Source user it might well belong here too...
Has anyone seen on jakarta commons the VFS project? Other than having
more than one duplication with the Excalibur Source concept
(suggesting me that it might be worth considering some sort of
cooperation between the projects), it made me think about a VFS-based
Source implementation, which would buy us a bunch of new and useful
protocols.
Yep.
Yet I'm wondering if someone has thought about it before since it
seems pretty trivial to me to implement some sort of wrapper on top of
it: I'm then asking, then, if there is something I'm missing or if
this possible integration was just overlooked.
I found VFS when I wrote the CVSSource, but left it since there was
nothing CVS-related there. However, I found it interesting to write a
CVS provider for VFS, but the architecture seemed to me heavy compared
to what's needed to write a Source. I also didn't have the necessary
time to dig a lot.
Thoughts?
Time for a VFSSource ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Cocoon core classes graph
Nicola Ken Barozzi wrote:
Sylvain Wallez wrote, On 29/03/2003 10.12:
Nicola Ken Barozzi wrote:
I'm developing a code graph viewer, and I tested it on cocoon.
See it here:
http://cvs.apache.org/~nicolaken/whiteboard/
Cool, although hardly usable given the width/height ratio, unless you
want to pin it on the wall all around the room ;-)
Yeah... I'm doing a graph that shows *all* core classes, and on screen
the real-estate is what it is.
Hey, what about feeding this information into Stefano's Agora ? Social
engineering applied to Java classes ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Cocoon core classes graph
Nicola Ken Barozzi wrote:
I'm developing a code graph viewer, and I tested it on cocoon.
See it here:
http://cvs.apache.org/~nicolaken/whiteboard/
Cool, although hardly usable given the width/height ratio, unless you
want to pin it on the wall all around the room ;-)
I'm impressed by the arrow routing algorithm that avoids crossing boxes.
Is it a standard feature of dot ?
I also noticed a comment in the SVG source mentioning For user: Bill
Gates. Damn, is M$ reverse-engineering Cocoon ???
;-P
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [ANN] XMLForm as a standalone servlet toolkit
ivelin wrote:
That is not the issue. We mean that a community member
would discuss any perceived issue with their peers. You did
not provide cocoon-dev with feedback or notify about a problem.
Over the last few months I have asked multiple times when is 2.1 going to be
labeled Alpha.
Maybe you did not follow my messages.
When I indicated the problem with the ever moving and always about to be
ready HEAD,
Sylvain Walez told me to hush, because I was ruining the good spirit of the
community.
Are you referring to
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=104421545406191w=2 ?
I never told you to hush, but said that, rather than complaining about
others having broken your XMLForm contribution, you could also get
your hands dirty and help fix it or at least give constructive comments.
The community I was referring to is Avalon, which has been hit so hard
by code ownership problems. And we, Cocoon community, don't want to see
this happen here.
Also, you asked several times when will 2.1 be released ? If this is
an itch that scratches you, then why not - again - getting your hands
dirty, if not on code, at least on a task schedule or some proposals ?
An OSS community is a loose group that is driven by the desires and
needs of its members. You cannot expect others to do something for you
unless then find some interest in it. And complaining is not the right
way to gain people's interest.
And now you tell us that many people asked you privately about XMLForm.
Have you read Cocoon's Who we are page ? It says : We ask that you
please do not send us emails privately asking for support. We are
non-paid volunteers who help out with the project and we do not
necessarily have the time or energy to help people on an individual
basis. Instead, we have setup mailing lists which often contain hundreds
of individuals who will help answer detailed requests for help. The
benefit of using mailing lists over private communication is that it is
a shared resource where others can also learn from common mistakes and
as a community we all grow together.
Why haven't you mentioned the problems raised by the private emails you
received to the list ? We could have solved them _together_.
snip/
At least *I* honstely don't see a good reason for XMLForm
becoming it's own Apache project - sorry.
Others disagree with you.
I have been asked numerous times via private emails, if it
can be used independently for smaller projects?
It can be cleanly isolated and interfaced with cocoon via
some sort of adapter.
This only confirms the value and need for blocks.
Then why don't you stay and help us sort out the blocks.
You are INcorrectly assuming that I have left Cocoon.
There are a lot of people with strong opinions on the blocks.
I do not feel like I can be of value at this stage.
Nevertheless I am monitoring the progress and looking forward to a final design
decision and an API.
There is no better place to ensure clean separation and
adaptability than here on cocoon-dev. We would actually
help clean up the xmlforms code, but going your way you
are on your own.
I like Bertrand's idea of going Chaperon or jfor's way.
Preliminary note : I'm a happy JFor and Chaperon user.
IMO, Chaperon and JFor may be considered differently than XMLForm : one
of the main evolutions of Cocoon is going through is growing from a
publication framework to a web application framework. Flow script and
XMLForm are two important parts in this evolution. My opinion is that
XMLForm is more core to Cocoon than Chaperon and JFor.
I see no reason why discussion should not be carried on cocoon-dev.
In fact it already started... ;)
I feel bad that it started somewhat sour, but I'm sure we'll work it out.
Ok, so please explain us what are the problems that were raised in
private emails.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [ANN] XMLForm as a standalone servlet toolkit
ivelin wrote:
The difference is that we all chipped in as part of the
community to help finish the re-factoring. All that we
heard from you was bleating from the sidelines, urging us
to release a product that is not ready.
You should probably speak for yourself instead of hiding behind we all.
It is by far not a proven fact that waiting forever for the perfect release
serves this project better than releasing smaller increments more often.
I will not enumerate the other people who are no less valuable contributors
and were also bleating about the release cycle.
Please stop enumerating people's contributions. All that is in Cocoon's
CVS is owned by the community. Sure, we are more concerned by what we
initially wrote, but, as a committer, you can update anything anywhere.
It should probably ring a bell to you when people are back porting XMLForm
into 2.0 just so they can use it in a stable release.
A few questions : why haven't *you* back ported XMLForm into 2.0 ? What
prevented *you* to do it ? And if other people did it, why haven't *you*
incorporated their patches in the 2.0 branch, if this is something that
itches you so much ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: flow problem
Ugo Cei wrote:
Stefano Mazzocchi wrote:
I just found out that the current flow implementation doesn't allow
the flow to access internal-only pipelines.
I noticed the same thing on this list some time ago.
I'm asking because I wish it was possible to send internal-only
pipelines to the user from the flow. This would make it *super easy*
to implement an authentication framework using the flow and provide a
very solid foundation for writing secure web applications.
Furthermore, views called by the flow _have_ to be internal-only :
calling them directly doesn't really make sense since the flow passes
them model data.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [ANN] XMLForm as a standalone servlet toolkit
Torsten Curdt wrote:
Let me explain, maybe the goodwill will prevail.
Otherwise this will turn into another example of a sad finish of an
exciting
jorney.
snip/
I am sure goodwill is a main reason but some question come to my mind
*) why don't you wanna share your thoughts with us and let us
(or at least some of us) together steer the direction of XMLForms?
*) how do you wanna contribute back? this might become harder as
we currently might think. the standalone version thing really
points that way.
*) project and communication wise this might give an unwanted
perspective that XMLForm might not be maintained under the
cocoon umbrella anymore. not a good marketing...
*) why don't you go the scratchpad way?
Now, let's do some constructive talking.
You probably remember the endless threads that were started in the
last few
months regarding the complexity of Cocoon and the fact that it
continuously
misses its release dates.
I am only refering to them to point out that not everything is perfect
around here.
More specificly:
As it stands XMLForm is way behind the XForms standards.
Is that the main reason for this - you wanna catch up with the XForms
standard?
snip/
So, Stefano, since you have your PMC chairman hat on, tell me if we can
create an incubator project.
I will gladly commit the new code to it.
If not, what other options do you suggest.
At least *I* honstely don't see a good reason for XMLForm becoming it's
own Apache project - sorry.
Why not scratchpad?
I fully agree with the above.
Ivelin, if you have some ideas about XMLForm, why don't you want to
discuss them here ?
Also, one of the purpose of blocks is to allow different areas of Cocoon
to have different levels of maturity : a block can be marked as
alpha/unstable. So why not working with the community in an XMLForm2
block ?
XMLForm is an important new feature in 2.1, and many people already use
it. So let's make it better together here.
What I foresee if you fork it is that Cocoon's XMLForm will evolve
quickly in response to its user feedback, while you will be let alone on
your side with your fork with no community to provide you features and
enhancements. Is this what you want ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Unnamed selector error message
Roberto wrote:
hello, I try to develope a portal with cocoon, but I obtain this error
message when I try to do some modifications on my sitemap.
_UnnamedSelector: ComponentSelector could not find the component for
hint []_
But the strange is that when I restore my old sitemap ( that worked
well ) I obtain the same error message! I try to reboot my system, but
it doesn't change anything. The only way to resolve the problem is to
re-install cocoon, put my old sitemap and all work well...
How can I resolve this problem?
Won't be able to solve the problem without a full stacktrace...
But what is sure, is that there should be no reason for which you should
_reinstall_ Cocoon. What may happen, however, is that some dirty files
are still present in your servlet engine's work directory that make the
failure persistant. Deleting this directoy should at least restore
proper behaviour of you old sitemap.
Sylvain
If anyone speak italian I think that I can explain better the problem.
There are many italians here, but I can say your english is perfectly
acceptable ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: why do we have two http proxy generators?
Tony Collen wrote:
On Wed, 26 Mar 2003, Geoff Howard wrote:
I think there were big changes coming to the WSPG from Hussayn Dabbous
([EMAIL PROTECTED]). He was working with a committer to add support for
proxying the existing session (for single sign-on).
I checked out the HttpProxyGenerator and it appears to have most, if not
all of the functionality of the WebServicePoxyGenerator. I can't speak
for Hussayn's project, however. One solution would be to move the WSPG to
the Proxy Block and mark it as deprecated.
Or even remove it since it was never released !
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: why do we have two http proxy generators?
Pier Fumagalli wrote:
Sylvain Wallez [EMAIL PROTECTED] wrote:
Or even remove it since it was never released !
I'd like to triple check the functionalities and have some doccos before
removing it... I use the proxy block @ work, so hopefully I'll be able to
maintain it! :-)
Sure ! What I was saying is that there's no need to keep two classes
lying around : just make sure we keep one that has the full featureset
of both, and remove the other.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [HEADS UP] Cocoon CLI performance up 50%!
Nicola Ken Barozzi wrote:
First of all a big thanks to Upayavira for listening to my ramblings
on optimization strategies and creating well done concrete
implementation of them with excellent additional ideas.
Since he was not satisfied, he has also converted the CLI to
commons-cli, added a CLI config file (cli.xconf), and created the
Cocoon bean.
Hey, do we have a new Cocooner here? :-)
- o -
Now for the actual figures.
The 'original' run is done by taking Cocoon-2.1 CVS and doing build
docs. The numbers are taken from the CLI run-time figure, not the Ant
one.
To try the 'optimized' one, edit cli.xconf by changing
confirm-extensions=true to false. What does this entail? That all
files without extensions are outputted as-is, without appending a
proper extension. In sites that always use explicit extension, it
makes no difference.
Can you explain what's the purpose of confirm-extensions ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: treeprocessor question
Stefano Mazzocchi wrote:
Is it currently possible to write a sitemap without the
map:components element alltogether and let it inherit everything
from the above sitemap?
Yes. This is taken care of in SitemapLanguage.java
If not, why?
If so, there are issues with this?
Issues ? No that I'm aware of...
Stefano Mazzocchi wrote:
is error-handling inherited?
Yes : if a map:pipeline has no map:handle-errors, exceptions are
propagated to the parent sitemap, and so on up to CocoonServlet.
if not, why?
if so, are there any drawbacks?
Drawbacks ? No that I'm aware of... ;-)
Mmmh... you're in telegraphic mode, today ;-P
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Who's/what is Yoshi ?
Hi all,
The flow PetStore demo uses a yoshi object to hold a couple of utility
objects such as a DateFormat.
So far so good, but what does Yoshi mean ? I guess it's a Japanese
word, but Google gives some funny results :
- Yoshi the pig : http://www.slip.net/~atombee/yoshi2.html
- Yoshi the iguana : http://users.erols.com/ziring/yoshi.htm
- or is it the Nintendo game ? http://www.yoshisstory.com/
Cheers,
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [vote] Andrew Savory as Cocoon committer
David Crossley wrote:
I propose Andrew Savory as Cocoon committer. He has been
involved with Cocoon since mid-2000 and more intensely during
the past year. Browsing the email archives i see plenty of
discussion, bug reports, testing, and suggestions. This indicates
his commitment. Andrew is also keen on documentation and has
already contributed in various ways.
Becoming a committer will allow him to contribute more effectively
to Cocoon.
I've met Andrew IRL, and I can say is committment to Cocoon is real.
So here's my +1
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [vote] Geoff Howard as Cocoon committer
David Crossley wrote:
I propose Geoff Howard as Cocoon committer. He has been
involved with Cocoon for the past year, providing lots of
useful discussion and bug report/fixing. He has submitted
many useful patches, for example with the file upload.
He gives tremendous assistance on cocoon-users, further
demonstrating his commitment to Cocoon.
Becoming a committer will allow him to contribute
more effectively to Cocoon.
There are some times when committer nominations are in the air : I was
recently thinking Mmmh... this guy is very active, he should be the
next one to be proposed...
So +1 !
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [proposal] a new kind of 'dist'
Stefano Mazzocchi wrote:
In the beginning, there was only one cocoon distribution, packaged
with two different packagers (zip for windows and tar.gz for unix and
friends).
Then cocoon became very complex and we decided to create a binary
distribution to make things easier. Things were indeed easier for new
users to install and try out, but it was harder for them to actually
*do* something with cocoon and tune it for their needs.
The fact that there is even a sourceforge project about a 'clean'
version of our shipped cocoon WAR feels a little like a slap in our face.
Then the 1.3/1.4 JDBC incompatibilities came out, forcing us to do two
different binary releases.
Now, in the light of a cleaned-up build system and a
very-well-factored-out static block architecture and the inclusion of
a super light-weight servlet container, I think we are ready to
finally go back to where we started and stop releasing binaries.
Before you jump up and down and scream no, no, binaries are easier
for our users, get off your
life-without-a-compiler-windows-inflicted-mindset and think that every
JDK comes with a compiler.
To be really honest, Cocoon already includes not one but *TWO* java
compilers!!! we could build from javawebstart if we really wanted to!
(we should also decide if we want to remove pizza from the distribution!)
So, in light of the good old triad
./configure; make; make install
I propose to ship Cocoon 2.1 *AS IS*, sort of a cleaned-up version of
our current CVS and improve a little the 'INSTALL.txt' doc that will
suggest you to do
snip/
What do you think?
Cocoon is now a major opensource product, and as such its user base
includes more and more people that are far less technically skilled than
we are. Moreover (I already mentioned this) the power of Cocoon's
builtin components leads to many people using it without ever opening a
Java source file.
Having to compile Cocoon by themselves will certainly refrain many of
them to go further than opening the box : they will close it quickly
and go away.
So I'm -1 for a source-only distro.
I also think a working Jetty-powered sample webapp is a must have in the
distro, since most often new users start learning Cocoon by playing with
the samples and modifying them.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [vote] micro-decision for docs: creation of cocoon-docs CVS module
Steven Noels wrote:
In order to get one little step closer to the 'new' document
infrastructure, many of us seek clarity whether we should move docs to
a separate CVS module or not. The benefits and downfalls are largely
known, so let's vote on this and get this issue cleared.
My own personal bias: don't forget the different Cocoon _versions_ are
now stored in separate modules, too.
Please cast your vote:
[X] creation of cocoon-docs module
[ ] docs should stay in src/documentation of the code tree module(s)
I don't clearly understand the second item : is it simply the negation
of the first one ?
To avoid to much disruption (we've seen recently how bad this is
perceived), I'm +1 too keep the docs in src/documentation until the new
cocoon-docs module is up to speed. This means that in the meantime,
src/documentation should be frozen : it stays there untouched until the
new system is ready. I prefer slightly outdated docs that no docs at all !
I also think Cocoon distros should include a static snapshot of the
docs. This means that the doc system should be able to identify
version-specific documents or even document parts to produce an adequate
documentation.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [proposal] a new kind of 'dist'
Stefano Mazzocchi wrote:
Geoff Howard wrote:
At 06:13 AM 3/24/2003, you wrote:
Niclas Hedhman wrote:
On Monday 24 March 2003 17:25, Christian Haul wrote:
This is an open *source* project, and a couple of things are a lot
easier to do at compile time rather than at run time.
Yes, like
./configure --prefix=/usr/local/
make
make install
for specifying installation directory, right?
Oh, please, that's not the case. Cocoon is *NOT* an application,
it's a framework. Our users are developers. They *MUST* be. What's
the point of having a joe-user-proof installation system to avoid
them to open up the hood when they *will* have to take the engine
apart anyway later?
Need to think beyond the power-programmer... Even the casual
programmer struggles with configure/make systems, and often fails
and leaves.
If the casual programmer is not able to do
export JAVA_HOME=/usr/java/
./build.sh webapp
./cocoon.sh servlet
that it does *US* a favor if he fails and leaves. Open source is not
about market share, it's about solid communities.
Cocoon cuts across a number of different disciplines (java, xml at
least?) and so casual programmer means different things.
Very true.
I am amazed at the number of people on users who claim to know no java.
Yes. This is going to be even more with the introduction of the flow
since people with client-side knowledge (html + css + javascript + xml
+ namespace + xslt) will be able to write full-blown web applications
with database connectivity *without* a single line of a language they
don't know nor understand.
This is potentially *HUGE*. Yet is a community shift that might find
*ourselves* not-prepared to stand the flood of those people and their
mindsets because most of us don't come from that background and people
in that client-side-web background have no notion of SoC, IoC nor any
abstract concept like OOP, COP or AOP, nor even the most basic design
patterns.
This cultural clash is potentially *very* harmful for both sides if
the mindset transition is not done smoothly.
Very clever analysis, which resonates with my view of the evolution of
software engineering since Java (or the web ?) appeared. The world of
developpers is more and more split in two categories those who build
components or frameworks, and those who use it. This is nothing new
compared to other domains of the human activity : you have house
builders and brick makers, you have electronic device designers and chip
makers, etc.
And Cocoon offers so high-level abstractions that people can use it
without caring about what's going on under the hood, even not caring
about Java.
Well, almost without caring, since Cocoon is sometimes a leaky
abstraction [1] ;-)
- they may be installing java for the first time, which (because of
sun's windows installer) may have no idea what JAVA_HOME is or should
be. They'll need to know this regardless, we just have to add even
this to the list of hurdles they already need to jump.
for windows, the sun's installer copies java.exe in the PATH, so we
need to have them set JAVA_HOME *ONLY* if there is no java.exe
available in path.
Be careful : what sun's installer copies into the PATH is a *JRE* and
not a JDK, which means you have no compiler. So they will end up with
something like NoClassDefFoundError: com.sun.javac.Main :-(
A solution can be for Cocoon to use one of the compilers it's shipped
with. Don't know if it's feasible, though.
snip/
I think this is YAGNI.
You like this acronym, eh ? ;-)
I say: let's start incrementally: we build one well-done
build.sh-driven distro and see what is the user reaction. *then* move
from there.
What do you think?
If we can solve the JAVA_HOME issue, then +0.
Sylvain
[1] http://www.joelonsoftware.com/articles/LeakyAbstractions.
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
[RT] ParentAware components (was:Re: Flow Scoping, was...)
Christopher Oliver wrote:
OK. I think you could get that effect by modifying
JavaScriptInterpreter.set/getSessionScope(). Right now these associate
the scope with the uri prefix of the current environment. Instead, to
get the behavior you describe, I guess it should be associated with
the top-most parent of the current sitemap that has a flow defined in
it. Any ideas on how to implement that?
What if a JavaScriptInterpreter was able to know the
JavaScriptInterpreter that exists in the parent sitemap ?
RT-starts/
This revives an idea I had a long time ago when writing the
treeprocessor : parent-aware components.
The elements in the map:component part of the sitemap are
ComponentSelectors (CS) with a special behaviour : they know their
parent, i.e. the component that has the same role in the parent
ComponentManager (handled by the parent sitemap), in order to implement
component inheritance : if a CS is asked for a component it doesn't know
of, it delegates the call to its parent. It is parent-aware.
This is not useful only for sitemap component selectors if we consider
the fact that map:components is nothing more than an xconf file.
Consider for example datasources : we have defined global datasources in
cocoon.xconf, and want local datasources defined (and visible) only in a
particular subsitemap. Currently, if we write datasources in
map:components, we hide global datasources. If we used parent-aware
selectors, we could _augment_ the set of available datasources. The same
can be used for InputModules.
Up to know, I thought this behaviour could be mostly useful for
ComponentSelectors, but the Interpreter use case proves that it can be
useful for regular (i.e. non-CS) components as well.
Implementation-wise, I'm thinking of defininig parent-aware by a new
lifecycle interfacee :
public interface ParentAware {
public void setParent(Object parent)
}
Any component implementing this interface will be given once (before
initialize()) the object that implements the same role in the parent
component manager.
Thoughts ?
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: cocoon-view as possible security problem?
Stefano Mazzocchi wrote:
Tony Collen wrote:
Browsing the livesites, on a whim I tried this URL:
http://dir.salon.com/?cocoon-view=content
and it worked! Obviously someone deploying Cocoon should be aware that
this view is on by default, and may reveal data in your page you might
not want. I have yet to see bad data get exposed, but there's always
the possibility.
Well, the cocoon view was designed to be a standard way for external
crawlers or spiders to gather 'semantically meaningful' data from URLs
served by cocoon.
yes, there is the possibility of bad data exposed.
Do we want the views turned off by default, and have a message in the
sitemap about enabling the views? Would it make more sense to have
thename of the cocoon-view parameter be able to be changed via
configuration? Say I wanted the parameter to be my-view instead of
cocoon-view. Security through obscurity?
Ok, some thoughts:
1) security thru obscurity is bad habit and we should avoid this.
2) views do not cause a security problem for someone that *knows* what
views are and why they are there
3) but I agree that not many do.
4) if we make that parameter configurable, the *WHOLE* point of having
views disappears since crawlers don't have a way to tell how to ask
for a specific view.
NOTE: a crawler should be allowed to ask for a specific view setting
an HTTP header in the request. The use of the 'cocoon-view' parameter
is a hack. We are aware of this. It's a hack because no browser allows
you to set the http headers directly, nor there is a portable way to
do this via javascript. Since views are useful for debugging, we
allowed this way of asking for views.
So, at the end, I would do:
1) turn off views from the default sitemap. NOTE: this will turn off
the ability to make static snapshots of your webapp from the cocoon CLI!
2) write a pretty detailed comment in the default sitemap telling what
views are, how they work briefly and what potential security issues do
they make.
3) keep the view parameter name hardcoded as it is.
Thoughts? anybody against this?
What about simply adding an IP matcher in the view that would restrict
access to the view to a reserved set of clients (localhost by default),
and direct others to a nice page, or simply a 404 error ? This would
leave the door open to local debugging and crawnling, and would firmly
close it to remote attacks.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Developer and Deployment Concerns
Berin Loritsch wrote:
unrelatedI would really like to see [EMAIL PROTECTED]/unrelated
With the view related security issues that have arrisen, we have to look
at some realities of development and deployment. They have some
potentially conflicting concerns.
This reminds me of a discussion back in september (see [1]) about
running modes. Some of the concerns you address can be solved by having
various components adapt their behaviour depending if Cocoon runs in
development mode or in deployment mode, and thus providing more
unsecure features at development time while being more strict at
deployment time by just changing a flag in a configuration file.
Sylvain
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=103175546321320w=2
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Problem with JPetStore
Christopher Oliver wrote:
Sylvain Wallez wrote:
snip/
Does JavaScript, like Java, make a difference between primitive types
(stored by value on the stack) and object types (stored by reference)
? My understanding after some tests is that a difference is made.
No, there shouldn't be any difference. If there is, it's a bug. What
was your test?
Here's my test (see below). I modified the viewCategory function in
PetStore to track the value of skipResults, and observed that when you
use the browser back button and then reload the page, skipResults is
correctly restored but not foo.skip which is set to the same value.
However, I realize now that my analyzis of the result (special handing
of primitive types) was wrong. Writing skipResults = 1 in JavaScript
is equivalent to writing Integer skipResults = new Integer(1) in Java.
This means skipResults refers to a new object of type Integer. And the
reference to this object is restored when the continuation is restored.
function viewCategory() {
var categoryId = cocoon.request.get(categoryId);
var category = getPetStore().getCategory(categoryId);
var skipResults = 0;
var maxResults = MAX_RESULTS;
var foo = new Object();
foo.skip = skipResults + 0;
while (true) {
print(foo before = + foo.skip);
print(skipResults = + skipResults);
foo.skip = skipResults + 0;
print(foo after = + foo.skip);
var productList =
getPetStore().getProductListByCategory(categoryId,
skipResults,
maxResults);
.../...
Am I right in my understanding ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Problem with JPetStore
Christopher Oliver wrote:
Sylvain Wallez wrote:
Here's my test (see below). I modified the viewCategory function in
PetStore to track the value of skipResults, and observed that when
you use the browser back button and then reload the page,
skipResults is correctly restored but not foo.skip which is set
to the same value.
However, I realize now that my analyzis of the result (special
handing of primitive types) was wrong. Writing skipResults = 1 in
JavaScript is equivalent to writing Integer skipResults = new
Integer(1) in Java. This means skipResults refers to a new object
of type Integer. And the reference to this object is restored when
the continuation is restored.
Yes, that's correct.
Cool.
Now can you help me with this problem:
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=104818906732548w=2 :)
Ok, I'll give it a look over the week end (it's past 8pm european time)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Problem with JPetStore
Tony Collen wrote:
On Fri, 21 Mar 2003, Sylvain Wallez wrote:
Christopher Oliver wrote:
Sylvain Wallez wrote:
snip/
Does JavaScript, like Java, make a difference between primitive types
(stored by value on the stack) and object types (stored by reference)
? My understanding after some tests is that a difference is made.
No, there shouldn't be any difference. If there is, it's a bug. What
was your test?
From http://www.forerunners.org/WebLibrary/jscript/ch09_03.htm :
The basic rule in JavaScript is this: primitive types are manipulated by
value, and reference types, as the name suggests, are manipulated by
reference. Numbers and Booleans are primitive types in
JavaScript--primitive because the consist of nothing more than a small
fixed number of bytes, bytes that are very easily manipulated at the low
(primitive) levels of the JavaScript interpreter. On the other hand,
objects and arrays are reference types. These data types can contain
arbitrary numbers of properties or elements, and so can be of arbitrary
size, and cannot be so easily manipulated. Since object and array values
can become quite large, it doesn't make sense to manipulate these types by
value, which could involve the inefficient copying and comparing of large
amounts of memory.
AFAIK, that's just like Java.
Christopher says that Rhino makes no difference between object types
and primitive types. Now if we consider primitive types as being
represented like the immutable objectified Java primitive types
(Integer, Boolean, etc), there's not much difference between passing an
immutable object by reference and a real primitive type by value.
But that's nitcpicking ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] Flow as a block
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
But won't work :-(
:)
Why ? Well, yes, a sitemap element = a builder class. But the
configuration file that defines them is used to feed a
ComponentSelector, which will try to load the class and the result is
that you will get an Exception in the initialization phase of the
TreeProcessor...
The only viable solution is for the declaration to be _not present_ in
the treeprocessor configuration.
This is not the best solution, as it would required to change the
treeprocessor conf for adding/removing flow.
Could the treeprocessor check the availability of a class before feeding
it into the selector? If the class is not available, a dummy implementation
could be perhaps added that could - when used - throw a meaningfull
exception.
Well, this would mean rewriting a ComponenentSelector specifically for
this purpose, since the TreeProcessor does nothing more than delegating
all this stuff to a CS : see DefaultTreeBuilder.createBuilderSelector().
Mmmh... A good solution may be to have a FakeFlowNodeBuilder that
delegates to a RealFlowNodeBuilder if it's present in the classpath, and
otherwise fails with a nice error message saying that the flow isn't
installed.
That way, we don't have to open wide the sitemap language definition,
which could lead to abuses : map:flow becomes an optional element that
is however pre-configured in the sitemap definition. Just drop in the
flow jar and it becomes available, without touching a single
configuration file.
Thoughts ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
CVS problem ?
Folks,
I'm experiencing problems while updating cocoon-2.1 (cocoon-2.0 is
fine). I get the following messages and then CVS seems to hang :
cvs update: Dropping data: posvec-nlines
cvs update: invalid change text in src/idl/cocoon/_module.idl
cvs server: cannot open directory
/home/cvs/cocoon-2.1/src/idl/cocoon/flow: No such file or directory
cvs server: skipping directory src/idl/cocoon/flow
Are you also experiencing this ? Any idea ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: CVS problem ?
Joerg Heinicke wrote:
Had the same yesterday. You simply must delete one of the ancestor
directories of the file and update again.
That solved the problem, although it doesn't explain how my CVS repo got
corrupted...
Anyway, thanks a lot for the trick !
Sylvain
Sylvain Wallez wrote:
Folks,
I'm experiencing problems while updating cocoon-2.1 (cocoon-2.0 is
fine). I get the following messages and then CVS seems to hang :
cvs update: Dropping data: posvec-nlines
cvs update: invalid change text in src/idl/cocoon/_module.idl
cvs server: cannot open directory
/home/cvs/cocoon-2.1/src/idl/cocoon/flow: No such file or directory
cvs server: skipping directory src/idl/cocoon/flow
Are you also experiencing this ? Any idea ?
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Discussion of Flow Issues
Stefano Mazzocchi wrote:
Christopher Oliver wrote:
snip/
Only because of the design of XMLForm: it stores the form view in
the object model and several of the methods of
org.apache.cocoon.component.xmlform.Form require the object model as
a parameter.
Ah, ok.
Regardless of the flow, there doesn't appear to be lot of consistency
in the way Cocoon components communicate: sometimes they stash stuff
in request parameters, sometimes in the session, sometimes in the
object model. In any case there seems to be no explicit contract,
I'm all in favor of discussing the introduction of such explicit
contract and make the system coherent. Do you have something in mind?
We have to define the various scopes of each of these elements :
- context attributes : global to the application (i.e. to all users)
- session attributes : per-user values, common to all requests for a user.
- request attributes : per-request values, common to all internal
requests (i.e. cocoon:) used to handle an external request
- object model : nearly per-request values, nearly meaning for the
current request (be it internal or external) and all descendant internal
requests.
That being said, I don't know if XMLForm should use request or object
model...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] Flow as a block
Stefano Mazzocchi wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
But won't work :-(
:)
Why ? Well, yes, a sitemap element = a builder class. But the
configuration file that defines them is used to feed a
ComponentSelector, which will try to load the class and the result is
that you will get an Exception in the initialization phase of the
TreeProcessor...
The only viable solution is for the declaration to be _not present_ in
the treeprocessor configuration.
This is not the best solution, as it would required to change the
treeprocessor conf for adding/removing flow.
Could the treeprocessor check the availability of a class before
feeding
it into the selector? If the class is not available, a dummy
implementation
could be perhaps added that could - when used - throw a meaningfull
exception.
Well, this would mean rewriting a ComponenentSelector specifically
for this purpose, since the TreeProcessor does nothing more than
delegating all this stuff to a CS : see
DefaultTreeBuilder.createBuilderSelector().
Mmmh... A good solution may be to have a FakeFlowNodeBuilder that
delegates to a RealFlowNodeBuilder if it's present in the classpath,
and otherwise fails with a nice error message saying that the flow
isn't installed.
That way, we don't have to open wide the sitemap language definition,
which could lead to abuses : map:flow becomes an optional element
that is however pre-configured in the sitemap definition. Just drop
in the flow jar and it becomes available, without touching a single
configuration file.
Thoughts ?
I personally don't like it. Adding fake facades for just one thing
doesn't sound right at all.
I think that Carsten's problem is to have an external dependency on
the rhino jar. Please, Carsten, correct me if I'm wrong.
Now, if my sitemap doesn't use *any* flow elements, would the jar need
to be in the classloader?
Nope, since the flow-related treeprocessor classes deal with flow
interfaces rather than with the JS implementation. So we need the
flow-related interfaces (only o.a.c.c.flow.Interpreter AFAICS) to be
present in the core, but can perfectly live without the implementation jars.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Strengthening setup() contract
Vadim Gritsenko wrote:
Jeff Turner wrote:
Hi,
Generator, Reader and Transformer all inherit from
SitemapModelComponent, which declares the setup() method:
public interface SitemapModelComponent extends Component {
/**
* Set the codeSourceResolver/code, objectModel
* codeMap/code, the source and sitemap codeParameters/code
* used to process the request.
*/
void setup(SourceResolver resolver, Map objectModel, String src,
Parameters par)
throws ProcessingException, SAXException, IOException;
}
If there's no objections, I would like to:
- assert in the Javadoc that 'src' will never be null
Some generators do not require src attribute.
Yep.
- modify AbstractProcessingPipeline to ensure this, and throw meaningful
exceptions otherwise.
Currently, leaving out the 'src' attribute causes a typically unhelpful
Cocoon error message:
java.net.MalformedURLException: Invalid System ID
May be add more helpful message to the AbstractGenerator /
AbstractTransformer?
Nope, as we still don't know there if the src attribute will be of
real use. This is the job of each concrete implementation, or at least a
common superclass that actually does something with the src.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Strengthening setup() contract
Jeff Turner wrote:
At that level, there isn't enough info to provide a user-friendly error
message. I think the best solution is to add a check in the
treeprocessor's ReadNodeBuilder. I've now got it displaying:
Reader at
file:/home/jeff/apache/xml/xml-forrest/build/webapp/sitemap.xmap:135:50
must have a 'src' attribute
Same applies to readers : you may have some readers that don't need an
'src' attribute. Please, let this be handled by the components that
actually require it.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [proposal] fixing the encoding problems
Gianugo Rabellino wrote:
Stefano Mazzocchi wrote:
If you start adding the environment, this is not true anymore and we
must cache *BOTH* the pipeline output (as xml) and the serializer
output (as binary) because their ergodicity can be different.
This is the only concern I'm having.
If enough people believe this is a small price to pay, well, I'll
turn my -1 into a -0 for giving Environment access to the Serializers.
Given that caching seems to be an almost-non-issue and that we seem to
be pretty convinced that this would not break the overall design,
here's +1 to add SitemapModelComponent to serializer into
SitemapModelComponent. Of course we have to take into account a
migration path for all the existing serializers (though it should be
enough to add empty impls to AbstractSerializer: AFAIK every concrete
Serializer in Cocoon inherits from it).
Mmmh... are you sure every Serializer extends AbstractSerializer ? Maybe
our's, but aren't there some custom serializers out in the wild world
that don't ?
It would be better for the pipeline to handle the optional case where a
Serializer also implements SitemapModelComponent.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Problem with JPetStore
Hi,
I'm playing and digging in flow-enabled petstore (BTW, so nice, I love
it), and experienced some problems with the continutation-enabled
prev/next navigation.
To reproduce it, go to the dogs area, click next once and then hit
the browser's reload button. The prev and next links are now totally
screwed.
Any ideas on what's going on ?
Moreover, AFAIU, the productList variable in viewCategory() is stored
in the continuation, and so if we hit next and then prev, the first
list exists twice (in different continuations). Isn't there a potential
memory consumption problem ? I know continuations expire, but withing
the expiration delay, all these lists keep floating around...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Problem with JPetStore
Christopher Oliver wrote:
Sylvain Wallez wrote:
Hi,
I'm playing and digging in flow-enabled petstore (BTW, so nice, I
love it), and experienced some problems with the
continutation-enabled prev/next navigation.
To reproduce it, go to the dogs area, click next once and then
hit the browser's reload button. The prev and next links are now
totally screwed.
Any ideas on what's going on ?
Yep. It's a bug. Here's a fix:
Thanks :)
Moreover, AFAIU, the productList variable in viewCategory() is
stored in the continuation, and so if we hit next and then prev,
the first list exists twice (in different continuations). Isn't there
a potential memory consumption problem ? I know continuations expire,
but withing the expiration delay, all these lists keep floating
around...
Yes, but the only things that are really duplicated are the program
counter and stack frames, and even the stack itself is lazily copied.
The local variables themselves (like productList) are shared between
continuations.
What do you mean by lazily copied ? Doesn't it need to be actually
copied to be stored ?
Also, how can local variables be shared between continuations if their
value changes between calls to sendPageAndWait, as is the case of
producList ? Isn't it contradictory with the continuation concept which
should restore variable values ?
Sorry for these newbie questions. Is there any docs that explains all
this ? If found your post about JavaScript for Java programmers but it
doesn't give any details about this.
Also, how are handled global variables ? AFAIU calling createSession()
attaches them to the session, but what if createSession() isn't called ?
And what is the relationship between global variables and continuations ?
That being said, it is still possible to explicitly free memory when a
continuation is captured, using this extended JavaScript syntax:
snip-example/
Thanks for your explanations,
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Problem with JPetStore
Christopher Oliver wrote:
Sylvain Wallez wrote:
Christopher Oliver wrote:
Sylvain Wallez wrote:
Moreover, AFAIU, the productList variable in viewCategory() is
stored in the continuation, and so if we hit next and then
prev, the first list exists twice (in different continuations).
Isn't there a potential memory consumption problem ? I know
continuations expire, but withing the expiration delay, all these
lists keep floating around...
Yes, but the only things that are really duplicated are the program
counter and stack frames, and even the stack itself is lazily
copied. The local variables themselves (like productList) are shared
between continuations.
What do you mean by lazily copied ? Doesn't it need to be actually
copied to be stored ?
What I mean is if you have a call chain:
function f() {
g();
}
function g() {
h();
}
function h() {
while (true) {
sendPage(...);
}
}
The call frames that represent the calls to f() and g() are shared
between all continuations captured inside h(). But when a continuation
escapes the while loop and returns to g(), then, at that point, a copy
of the call frame of g() is made, and so on as you return up the stack.
Ah, I understand : common stack frames are shared between continuations
having the same ancestor continuations.
Also, how can local variables be shared between continuations if
their value changes between calls to sendPageAndWait, as is the case
of producList ? Isn't it contradictory with the continuation concept
which should restore variable values ?
No. That's the intended behavior - just like in Scheme. Invoking a
continuation only restores the program counter. It does not roll back
changes to other data. That behavior would be way too expensive! As it
is the cost of invoking a continuation is negligable.
Mmmmh... I guess what you mean here is that the PC and the stack frame
are restored, which also includes local variables. What isn't restored
is the state of objects pointed by these local variables.
Does JavaScript, like Java, make a difference between primitive types
(stored by value on the stack) and object types (stored by reference) ?
My understanding after some tests is that a difference is made.
Sorry for these newbie questions. Is there any docs that explains all
this ? If found your post about JavaScript for Java programmers but
it doesn't give any details about this.
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=102781075226697w=2
Wikified at
http://wiki.cocoondev.org/Wiki.jsp?page=RhinoWithContinuations !!
Thanks,
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Discussion of Flow Issues
Ugo Cei wrote:
Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
1) do we really need the session object? the flow is in fact
deprecating the use of sessions for storing stateful data. I would
love to *force* people to think into this way by not making the
session available to them. We can always add it later if users
really push us for it.
+1. Moreover, the inadequate use of sessions to store data my
completely break what the flow is giving us through continuations.
I'm using the flow and I'm using sessions too. The applications I'm
currently developing with the flow are composed of many independent
flows, each with its own entry point. Consider the case of an
e-commerce site. These entry points might be:
- search for an item
- add item to cart
- show cart
- delete item from cart
- proceed to checkout
I don't think I can combine all of these (and many more) in as single
flow, held toghether with continuations. But I still have the need to
have a user session spanning those operations, and I do this with
per-session global variables in the flow. As you might know, global
variables in a flowscript are associated with a session when you call
cocoon.createSession(). In the above example, the cart, or the user's
profile, would be associated with the session.
This is something that I don't fully understand : when you call
cocoon.createSession(), global variables of the various scripts of a
given sitemap are shared through the session. This means, AFAIU, that
each user has then its own independent set of global variables. Is this
right ?
But to what are these global variables attached when
cocoon.createSession() hasn't been called ?
Moreover, shouldn't this createSession() method be named
setSessionScope() or something like that, since it does actually more
than simply creating the session ?
I am somehow aware that I am abusing sessions here, and that there is
a better way, but it's not that easy to follow, probably. If you can
show it to me, I'd be glad to abandon sessions, but if you take them
away right now, I'm going to be in trouble ;-).
Session are always available through the good old
request.getSession(). But I'd like to avoid the session to be created
implicitly by the flow engine since not every application needs it.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [rt] resource-exists selector
Vadim Gritsenko wrote:
Jeff Turner wrote:
(note: [rt]'s are little [RT]s ;)
...
So, can I check this in, deprecate ResourceExistsAction, and we all
live happily ever after?
Check in resource-exists selector: +1.
+1 also.
Deprecate resource-exists action: +0.
+0 also ;-)
What about resource-exists matcher? ;-)
PS: RT: 1st rule of sitemap component equivalency: Every action could
be renamed to/rewritten as a matcher
Every action *that only performs some checks and doesn't modify the
system state* could be renamed to/rewritten as a matcher.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [rt] resource-exists selector
Jeff Turner wrote:
Heh.. I think you're right. Matchers, Selectors and Actions are all
switches that can do logic. Actions have an unfair advantage in that
they get passed a SourceResolver. I actually wrote a
ResourceExistsMatcher first, then decided a Selector was more
traditional.
In Cocoon 2.1, the SourceResolver is a regular component that any
Composable can get through the traditional lookup() method. Actions
advantage is gone !!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [rt] resource-exists selector
Vadim Gritsenko wrote:
Steven Noels wrote:
On 18/03/2003 15:12 Vadim Gritsenko wrote:
PS: RT: 1st rule of sitemap component equivalency: Every action
could be renamed to/rewritten as a matcher
Hehe.
2nd rule: any selection of Matchers can be combined into a Selector :-D
Bzzzt!!! Funny but wrong :)
Matchers have side effect by returning map of values.
What about some super-selector (or multi-match ?) that would be
allowed to return sitemap values ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [rt] resource-exists selector
Nicola Ken Barozzi wrote:
Sylvain Wallez wrote, On 18/03/2003 15.43:
Vadim Gritsenko wrote:
...
Matchers have side effect by returning map of values.
What about some super-selector (or multi-match ?) that would be
allowed to return sitemap values ?
And make Matchers and Selectors able to use the a MathcerSelectors as
a common implementation? That way I can make my
ResourceExistsMathcerSelector and use it both in a Matcher and a
Selector.
public abstract MatcherSelector implements Matcher, Selector
match(...){ calls matchOrSelect}
select(...){ calls matchOrSelect}
public abstract matchOrSelect(...)
{ override this for common functionality}
Wow, I love that !
[entering RT mode, with capital letters !]
Taking this idea further (selectors returning sitemap values), we can
consider that a map:match is equivalent to a map:select with a
single map:test, and that a map:select is a sequence or map:match.
We can even have the sitemap engine handle all this transparently
depending on the actual class of the component and handle all this
transparently !
And we end-up with deprecating the map:selectors sections in the
components by letting map:matchers hold any of the Matcher and
Selector interfaces...
Thoughts ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Discussion of Flow Issues
Pier Fumagalli wrote:
On 18/3/03 21:29, Christopher Oliver [EMAIL PROTECTED] wrote:
Stefano Mazzocchi wrote:
Another possibility is to only expose the session at the Java level
(not JavaScript) forcing new JavaScript objects that need access to it
to be written in Java. This might prevent abuse.
Hmmm, if you don't get a hook to the ObjectModel, how can you get a java
session object from the flow?
What I meant was instead of this:
public class JSCocoon extends ScriptableObject {
public Session jsGet_session() // expose session to JavaScript
{
...
}
}
we could do this:
public class JSCocoon extends ScriptableObject {
public Session getSession() { // not available in JavaScript
}
public static Session getSession(Scriptable scope) {
Scriptable topLevel = getTopLevelScope(scope);
Object obj = getProperty(topLevel, cocoon);
return ((JSCocoon)obj).getSession();
}
}
Then if you need access to a Session you would have to implement a
JavaScript object in Java, for example:
class MyObject extends ScriptableObject {
public String getClassName() {return MyObject;}
public void jsFunction_foo() {
// I need the session:
Session session = JSCocoon.getSession(this);
}
}
Then in javascript you could do this:
var obj = new MyObject();
cocoon.session; // undefined
obj.foo(); // but foo() uses the session
I like your approach _MUCH_BETTER_... I think we should consider it for most
of the stuff we make visible to the flow, rather than passing the real Java
instances to Rhino (obviously removing the construction part when needed)...
Mmmh, I don't like it much, as AFAIU it will require too much often to
write some glue code for things that could be written in JS only...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] Flow as a block
Carsten Ziegeler wrote:
Stefano Mazzocchi wrote:
SNIP/
So, perhaps Sylvain has a clever idea on how to implement this in the
treeprocessor.
I think that using xconftool is enough.
Yes, after thinking about it, for now we even don't need the xconftool
but a clever exception handling/message.
(Sylvain, correct me if I'm wrong)
The configuration for the tree processor defines for an XML element a
builder class. This builder is used when the sitemap contains this XML
element. My idea is now, that this builder class is only invoked,
when the XML element is used in the sitemap.
So, if you have flow installed, the corresponding builder classes are
available and you don't get any problem if you use flow or not.
If flow is not installed and you don't use flow, the builder classes are
not used - no problem.
If flow is not installed and you use flow, the builder classes are
tried to be used but not available - exception class not found
- clever message to the user.
Sound easy...
But won't work :-(
Why ? Well, yes, a sitemap element = a builder class. But the
configuration file that defines them is used to feed a
ComponentSelector, which will try to load the class and the result is
that you will get an Exception in the initialization phase of the
TreeProcessor...
The only viable solution is for the declaration to be _not present_ in
the treeprocessor configuration.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
