Re: Re: How I plan to move forward.

There is a caveat... comments below: This is more of a note to self.

On 2/19/06, Geoff Longman <[email protected]> wrote:
> 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


'Finding' is an expensive operation when it comes to peeking into jar files.
The current plugin seeks to avoid doing this whenever possible.

For me, Hugo and other IDE implementors the trick is to have a very
efficent ISearch-er when it comes to finding resources in jar files.


> 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
>


--
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