[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[news.eclipse.technology.lepido] Re: What features do you want for Lepido?

Sandor Spruit wrote:

Sylvain Wallez wrote:

Sandor Spruit wrote:


[snip]

Like you mentioned above: flowscript or form definition refers to a
pipeline, quite implicitly, working by association. You mentioned this
in another thread. It can't be too difficult to scan a flowscript for
calls to 'sendPageAndWait', check sitemaps for the pipeline mentioned.


Hmm... checking for "sendPageAndWait" is certainly easy. Now finding the corresponding pipeline may not be that easy, unless we rewrite a lightweight sitemap engine (e.g. only basic matchers and selectors).


Now you know why I asked you about opening-up the sitemap API to tap into the sitemap's inner data structure - GetTogether in Gent.


Yes, I remember that :-)

Or is the sitemap engine so dynamic that it figures out all the details at runtime without building-up a true internal datastructure? Or maybe the entire structure is something like a compiled finite-state machine that is decoupled from the sitemap's pipeline definitions?


The sitemap instructions are translated to an evaluation tree (see TreeProcessingNode interface), when a sitemap is first executed, but all strings (patterns, sources, parameter, etc) are evaluated at runtime, and can depend on input modules that can use any source of information. That's where the difficult point is, and this is why static analysis will have to be restricted to a limited subset of what a sitemap allow.

Same story: create HTML in a XSLT stylesheet, introducing an IMG tag
that refers to an jpg-image while your sitemap does not have a pipeline
for jpg's, or the image file cannot be found on the file system.


Wow, even more hard to find IMO. Do you have some ideas in mind about how the underlying semantic and analysis model?


Hmmm. Would it be difficult to have a sort of 'test-run' mode in the sitemap? I mean: given a certain URL pattern, just *tell me* which pipelines/components will be used, but do not take any real action?
Maybe that is what you mean by a lightweight sitemap engine?


Cocoon is such a dynamic system that it test-run is only possible on a live application. By lightweight engine I was thinking to the restricted subset mentioned below. Basically, components whose behaviour is well-known and that don't have dependencies on the application status. This includes wildcard and regexp matchers and maybe a few input modules such as request-param.

Sylvain

--
Sylvain Wallez                        Anyware Technologies
http://apache.org/~sylvain            http://anyware-tech.com
Apache Software Foundation Member     Research & Technology Director