[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[news.eclipse.technology.lepido] Re: What features do you want for Lepido?
|
- From: Sandor Spruit <sandor@xxxxxxxx>
- Date: Tue, 26 Apr 2005 10:30:17 +0200
- Newsgroups: eclipse.technology.lepido
- Organization: EclipseCorner
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217
Sylvain Wallez wrote:
Sandor Spruit wrote:
Sylvain, others,
My 2 cents follow.
Key feature: being able to trace information flowing through Cocoon
from the moment a http request comes in. What components are
triggered? What information is exchanged between these components?
I think that's what people mean by a sitemap debugger?
Yep, but there's more to processing flow than only the sitemap. I'm
sure we'll want to step from the sitemap into a flowscript, then from
the flowscript back to the sitemap. See also my previous post about
this.
Sure. My component definition is broad enough to cover flowscript as
well :) Technically not correct, practically true. Perhaps I should say
building block and not component.
Really nice: check the sitemap against other files for consistency.
Many places in my Cocoon apps refer to the sitemap. FlowScript
contains links to pipelines, stylesheets contain references to
files that have to be matched with a pipeline. I often find myself
testing a Cocoon sniplet to find, for example, property files or
pictures unreferenced in sitemaps. Quite stupid, quite simple but
soooo easy to overlook. Could we scan the files for (relative)
URLs pointing to unmatched resources? Maybe a view on your project
where sitemap (left pane) and other elements (right) are combined?
A warning message when you add a resource to a project?
Sorry, I don't really understand this. What "resources" are you
talking about? Can you elaborate with an example?
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.
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.
Along the same line: having several sitemaps and subsitemaps where
some construct in the subsitemap won't work because there's an
overlap with a higher level sitemap. Not an error condition in the
strictest sense, but so easy to overlook. Frustrating. I seem to
remember that it's possible to check whether a regular expression
is a specialization/generalization of another regular expression?
Think: **/*.jpg and simple *.jpg
Definitely interesting, even if that requires a bit of "intelligence"
in the sitemap editor. It often happens in a single sitemap also.
This feature will require that we have some kind of semantic model of
the Cocoon application. A first version of this model can consist in
building the tree of match patterns to be able to quickly find such
overlappings and what pipeline will answer to a request. This model
won't be able to detect everything though, as it will be limited to
those matchers that can be executed without a runtime environment.
But with just regexp and wildcard matchers, we already cover a large
number of cases.
Definitely.
I like the idea of wizards. I think it would be easier for new
folks to grasp the Cocoon concepts if some frequently occurring use
cases would be 'prepared' in a template for them. I have recently
looked at Cocoon as a tool in our curriculum. Top issue: how to
explain the relationships between technologies? Part of the beauty
in Cocoon's design is that some *combination* of relatively simple
technologies solves a problem. Not a big fat concentrated blurp of
complexity. Consequence: you have to focus on everything working
together. And that's not really easy. A wizard maybe an excellent
idea to address this, as you can illustrate how your solution is
built-up which is better then an comprehensive example IMHO.
Ok. See my previous answer to Stavros about "snippet wizards". Is
this what you're talking about?
I'll quote you here to ensure we are talking 'bout the same thing:
"Yup. The problem I see coming with the semantic model that we'll have
to build is that many files in Cocoon depend on other files, but this
dependency isn't explicit. For example a subsitemap depends on its
parent sitemap but doesn't link to it. Same applies to a form
definition, template and binding which are all glued together by a
flowscript."
This is *exactly* why Cocoon is difficult to teach. Or indeed any web
technology. Implicit interdependencies. The really appealing aspects of
Cocoon require a larger context. Larger then folks that are "into it"
realize. If you could combine technologies in a scenario or wizard, the
power of Cocoon would be more visible and it would be easier to use.
Sandor