Re: Re: How I plan to move forward.
"Geoff Longman" <[email protected]> Sun, 19 Feb 2006 23:49:33 -0500
| Newsgroups | gmane.comp.ide.eclipse.spindle.devel |
|---|---|
| Message-ID | <[email protected]> |
The more I ponder this exclusion idea the more I like it.
I muse aloud.
In the existing plugin, libraries were only seen if they were
reachable (declared using a <library> tag). Which in combination with
some other stuff was why there was never a New Library wizard.
Old.
1. Resolve the Framework
2. scan web.xml, find the app spec location
- Resolve the child libraries (reachable)
- Resolve the application namespace
FYI - resolving means parse/validate namespace xml, find all
pages/components in the namespace, validate pages/components.
I already changed this so I could check for namepace collisions.
Resolving no longer includes parse/validate namespace xml.
1. parse/validate Framework
2. scan web.xml, find the app spec location
- Parse/Validate app spec xml
- Parse/Validate all child lib xml (reachable from application spec)
3. Check for collisions
4. Resolve Framework
5. - Resolve the child libraries
- Resolve the application namespace
Now I'm thinking that with the exclusion idea the 'Check for
Collisions' is less onerous (less likely to cause a fatal error) and
the new layout above would allow Spindle to resolve libraries that are
not reachable. Which is cool I think as long as an unreachable library
can be marked so to remind the user they need a <library> tag
somewhere.
1. parse/validate Framework xml
2. find all .library files everywhere & parse/validate them
3. scan web.xml, find the app spec location and parse validate it.
Now we have objects (with paths) for all the namespaces in the project.
4. Check for collisions - much simpler, just check for namespaces
sharing an exact path.
5. Resolve Framework
6. Resolve all the library namespaces.
Resolving a library in this 'standalone' way should be possible as a
library can't refer to it's parent namespace (indeed it could have
many parents or no parent if it was not reachable).
If the order of 6 is deepest path to shallowest path half the
'excluding' is done. The rest of the exclusion would be 'set up' if a
libray namespace 'laid claim' to the pages/components found by
recursive lookup then later namespaces couldn't pick up the same
pages/components (they've already been 'claimed').
7. Resolve the application namespace.
Without doing anything else a 'boundary crossing' reference to a
page/component would result in a 'no such component' error. A better
error message is called for.
Something to think about.
Geoff
On 2/19/06, Geoff Longman <[email protected]> wrote:
> > Unfortunately, I wasn't aiming the exclusions at the user - more for
> > Spindle. I agree that it should "just work" - and up until Tapestry
> > became "ultimately configurable" it seemed as though it did (99% of the
> > time anyway ;-) ). What I was looking at was a possibility of Spindle
> > doing recursive searches down a hierarchy and excluding any 'namespaces'
> > that have a library in them. Thus:
> >
> > /WEB-INF/foo.application would include everything except
> > /WEB-INF/bar/** if there was a bar.library under /WEB-INF/bar
>
> Yes, of course. I misunderstood.
>
> The recursive search is implemented already and your suggestion is a good one.
>
> I guess the namespace with the 'deepest' path would 'win' anything
> below it (path-wise) to the exclusion of any other namespace.
>
> Need to identify the corner cases though.
>
> what about
>
> /com/mystuff/foo.library
> /com/mystuff/bar.library
>
> or
>
> /WEB-INF/foo.application
> /WEB-INF/bar.library
>
> These are cases exclusions won't help solve.
>
> Perhaps relax the "namespaces are never to overlap" rule into
> "namespaces may never be colocated" (bad wording for sure).
>
> Hmm, pondering...
>
> >
> > As for being on crack - well... you are working endless hours on the
> > taming of the shrew(d Tapestry configuration options), aren't you? :-)
> > [and yes, all work VERY MUCH appreciated]
> >
>
> Thanks!
>
> Geoff
>
>
>
> --
> The Spindle guy. http://spindle.sf.net
> Get help with Spindle:
> http://lists.sourceforge.net/mailman/listinfo/spindle-user
> Blog: http://jroller.com/page/glongman
> Feature Updates: http://spindle.sf.net/updates
>
--
The Spindle guy. http://spindle.sf.net
Get help with Spindle:
http://lists.sourceforge.net/mailman/listinfo/spindle-user
Blog: http://jroller.com/page/glongman
Feature Updates: http://spindle.sf.net/updates
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642