[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, 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.
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?
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.
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?
That's all for now, gotta catch a train.
Well, this already gives a lot of interesting ideas!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://apache.org/~sylvain http://anyware-tech.com
Apache Software Foundation Member Research & Technology Director