Re: How I plan to move forward.

comments in line...

On 2/15/06, Hugo Palma <[email protected]> wrote:
> Here's my 2 cents.
>
> As far as component spec lookup rules are concerned i only see one problem.
> I'm not so sure that dropping rule (4) is such a good idea.
> Correct me if i'm wrong but with the reduced number of rules the component
> spec Component1.jwc would not be found in the following structure unless you
> declared the component in the application descriptor.
>
> context-root/WEB-INF/myapp/myapp.application
> context-root/WEB-INF/Component1.jwc
>
>  The problem is that i've used and seen this structure used too many times
> to think that the new lookup rules would not be too restrictive.
> This was the only problem i found in the lookup rules, everything else looks
> fine.

Keeping all the rules was possible in Spindle for T3 because of the
"Only allow one Tapestry app per project". If you ignore the "library
hosted in the context" issue the one project rule eliminated any
boundary crossing.

The same would be true for T4 but the identifiers-with-paths problem
rears it's ugly head. You have to drop rule 4 in oder to avoid:

Component2            --> /WEB-INF/myapp/Component2 .jwc
myapp/Component2 --> /WEB-INF/myapp/Component2 .jwc

Is it worse to not find the component at all, with an error marker, or
somehow detect multiple namings and (by some convention) "ignore"
goofy ones. Since, by the ordering of the rules, "relative to the
application spec" is more important than "relative to WEB-INF" the
naming "Component2" would trump the naming "myapp/Component2 ".

Internally, the core needs to have only one name -> jwc. So at
validation time a reference to "myapp/Component2" would not be
resolved. In Spindle 4T3 a message like "component 'myapp/Component2'
not found in the application namespace". Which is not really true in
T4 as 'myapp/Component2' is a valid identifier at runtime.

I'll give this more thought this evening.

>
>
> Moving on to the tradeoffs.
>
> (1)"Only allow one Tapestry app per project"
> - Fine by me. I see this as an overall best practice as more than one app
> per project tends to over-complicate things.
>
> (2)"Spindle projects must have a, possibly empty, application file"
> - I can't help but think that enforcing a user to create an empty is
> something that doesn't feel very natural. After all, what we really want is
> not the file, but the location of the file itself. So, maybe instead of
> forcing the user to create an empty file a choice could be given, either the
> file is indeed created or a "application root"(not sure this name is the
> best) configuration should be given(in the IDE) that points to the directory
> where the application descriptor would live if it existed. Am i making any
> sense ?

I think in the immediate term I'll stick with the tradeoff. It allows
me to get coding without having to handle the configuration data you
have suggested. Definitely something to be revisited. (gotta be
careful - there is a tradeoff between an irritating file requirement
and adding more IDE config functionality - I tend Iean towards liking
to have a convention over a configration dialog - ultimately the end
users will make the call).

Geoff

>
> (3)"Namespaces of any kind, application or library, must not overlap"
> - Like (1) this is an overall best practice so i see no problem with this.
>
>
> Cheers
>
> Hugo
>
>
>
>  On 15/02/06, Geoff Longman <[email protected]> wrote:
> >
> > [This is long but I describe some tradeoffs that would impose
> > (hopefully minimal) restrictions on how developers build their apps in
> > Spindle. I think with these tradeoffs I can get coding again. If
> > nothing else, look at the bottom of this message for a summary of the
> > tradeoffs. I solicit your feedback at the end also. G.]
> >
> > Obviously, there are a lot of challenges to be overcome to get Spindle
> > working with T4.
> >
> > As I was writing Pt.5 it occurred to me that perhaps if I tweak the
> > way Spindle applies all of the various "rules" I've been griping about
> > maybe I can get something done. I have not described all the problems
> > yet. The reason being that those undescribed problems are a bit
> > unclear to me at this time.The problems already discussed have really
> > blocked forward progress, so I I have not yet reached a point where
> > some of those less understood issues come into play.
> >
> > I'm going to apply choices/restrictions (from here on in referred to
> > as 'tradeoffs') as was already done to a certain degree in the
> > existing Spindle plugin and see if they can overcome the current
> > "problems"  and produce a reasonable model of a T4 application.
> >
> > This is a tricky bit of slight of hand. I think it's clear that a
> > perfect model of an app, using all the idiosyncrasies of the Tapestry
> > implementation is a lost cause.
> >
> > Any tradeoffs must:
> >
> > 1) still result in application that will run in an unmodified T4
> runtime!!!!!
> >
> > 2) Not eliminate any of the new features of T4 that make developer's
> > lives easier when switching toT4 Otherwise what's the point?
> >
> > 3) Be the minimum "imposition" on a developer needed to get Spindle to
> > work. Hopefully some of the impositions can be mitigated by
> > functionality in the GUI. (more on that in another message - when I
> > get to the GUI!).
> >
> > 4) Each imposition must be defensible. ie. hopefully in every case
> > when I say that "you can't do this" or "you need to do this" I can
> > justify the reasons are more than just an imposition for the sake of
> > the tool. Rather, it would be nice to say that "doing it this way will
> > result in better application, one that is less error prone and one
> > that is easier to maintain over the long haul".
> >
> > The first tradeoff will be to eliminate (as much as possible) the
> > conditions where namespace boundary crossing would occur.
> >
> > This is hard to defend in a short, easy to understand, way. Look at
> > how much text I've written about the problem. It took a very long time
> > to understand it myself and it's even harder to communicate to others.
> > I've even attempted several times to communicate this to the Tapestry
> > committers without success.
> >
> > So, how do I eliminate rule problems?
> >
> > Recall that rule problems cause namespace boundary crossing and the
> > crappy situation where two Tapestry 4 style identifier refer to the
> > same .jwc file.
> >
> > "Only allow one Tapestry app per project"
> >
> > I was really wanting to drop this restriction once and for all. But,
> > since there is no way to avoid having all specless pages exist in
> > every application namespace I have to keep the restriction.
> >
> > "Use a subset of the lookup rules" (This only impacts components/pages
> > that have .jwc/.page files!)
> >
> >
> > A judiciously chosen subset of the rules would wipe out the cases
> > where multiple names refer to the same spec file. And I suspect that
> > many user's would not notice the difference.
> >
> > How can I say that? Take the case of a new user to Tapestry. Most new
> > user's don't have multiple apps/war and they don't have a .application
> > file. In this case Tapestry installs the synthetic app spec in
> > /WEB-INF/servlet-name.application.
> >
> > Look at the component spec lookup rules again (i think this is the
> > first time I've included the entire set of T4 rules, previously I was
> > talking about the T3 rules or only parts of the T4 rules):
> >
> >   (1)As declared in the application specification
> >   (2)type.jwc in the same folder as the application specification
> >   (3)type jwc in the WEB-INF/ <i>servlet-name </i> directory of the
> context root
> >   (4)type.jwc in WEB-INF
> >   (5)type.jwc in the application root (within the context root)
> >   (6)By searching the framework namespace
> >   (7)By searching for a named class file within the
> > org.apache.tapestry.component-class-packages property
> (defined within
> > the namespace)
> >
> > [Rule 1 stays. The explicit definition of a .jwc file's location must
> > remain or one could argue that it's not Tapestry anymore.]
> >
> > Since the synthetic app spec is in /WEB-INF rule 2 and 4 are
> > effectively the same. In the above scenario we could drop either rule
> > 2 or 4 and nobody would be the wiser.
> >
> > But what if the application spec is not in /WEB-INF or the user
> > specifies another path altogether to a real application xml file? A
> > valid argument. Since prohibiting developers from explicitly placing
> > their real application xml file would be crazy. I say drop rule 4.
> >
> > What about rule 3? Well, if the user has a real xml file in that
> > location, then rule 2 trumps rule 3 and we could drop rule 3.
> >
> > Which leaves the case where the user does not have an xml file but
> > builds their app assuming that rule 2 would come into play.
> >
> > ie  use component name /a/path/to/MyComponent and expect rule 2 to find
> >
> > /WEB-INF/servlet-name/a/path/to/MyComponent.jwc.
> >
> > There is a kludge that could handle this case. When copying the
> > "create synthetic spec" behaviour, check to see if
> > /WEB-INF/servlet-name exists and install a synthetic spec there.
> >
> > It won't work. First, this is behaviour that Tapestry does not do
> > itself and so it "smells" bad to me. Second, what if the user has the
> > folder but put all the jwc files relative to /WEB-INF anyways? or has
> > some under /WEB-INF and some under /WEB-INF/servlet-name? Runtime
> > Tapestry is ok as rules 2 and 4 would both match when appropriate but
> > we would like to get rid of rule 4.
> >
> > Hmm, how to solve this pickle? I think that we will have to make
> > another tradeoff that might be hard to swallow...
> >
> > "Spindle projects must have a, possibly empty, application file"
> >
> > Ok, a wizard can generate the file. This is what wizards do. Every
> > project created with the wizard will have the file, no problem. The
> > wizard can also let the user choose where to place the file. If the
> > user deletes/moves the file, it's not tool's fault although it had
> > better give useful feedback identifying that there is a problem and
> > how to fix it.
> >
> > But if the project was created without Spindle, inside or outside the
> > IDE, there might be no file. Spindle needs to be able to give enough
> > feedback and docs (a cleanup tool would be nice) to help developers
> > "fix" their "broken" application.
> >
> > Now that I look at it, if the project must have a .application file,
> > the rules immediately collapse to:
> >
> >   (1)As declared in the application specification
> >   (2)type.jwc in the same folder as the application specification
> >   (5)type.jwc in the application root (within the context root)
> >   (6)By searching the framework namespace
> >   (7)By searching for a named class file within the
> > org.apache.tapestry.component-class-packages property
> (defined within
> > the namespace)
> >
> > as rules 1 & 2 would always trump rules 3 & 4.
> >
> > I'll hide 6 & 7 now as they play a role (unmodified) in a part of
> > Spindle separate from where rules 1, 2, & 5 come into play...
> >
> >   (1)As declared in the application specification
> >   (2)type.jwc in the same folder as the application specification
> >   (5)type.jwc in the application root (within the context root)
> >
> > Rule 5, hmm, this rule is a big boundary violator but if there is only
> > one app per project it might not be catastrophic to keep it. And since
> > Howard changed T4 (in the beta stage I think) so the WEB-INF is not
> > allowed in component names, I don't think rule 5 can screw up the
> > results of rules 1 & 2.
> >
> > The remaining set of rules is much more manageable. I think I can work
> with it.
> >
> > So, we have just cut out a lot of cases where the same T4 identifier
> > might refer to the same .jwc file. But not all (yet).
> >
> > Tapestry 4 allows libraries to be hosted in the context. Depending on
> > the placement of the .library file we could be back in the situation
> > where different identifiers refer to the same .jwc file.
> >
> > The easy answer would be to not allow libraries in the context. But,
> > as I look at libraries in general (context or classpath) I think there
> > is a way to allow libraries in the context with another tradeoff.
> >
> > Why can I say this? Because we need another tradeoff anyway to ensure
> > libraries don't overlap wherever they occur!
> >
> > Lookup rules for finding components in libraries are already even
> > simpler than our stripped down set of rules for components in the
> > context.
> >
> > here they are:
> >
> > (1)As declared in the library specification
> > (2)type.jwc in the same folder as the library specification
> >
> > ignore the following rule!
> > (3)By searching the framework namespace
> >
> > Libraries must always have a .library file already. So we are looking
> > at searches relative to the location of the .library file.
> >
> > We only run into problems if the relative searches for two libraries
> > overlap. When that can happen it is possible to have one .jwc file
> > cross multiple namespace boundaries.
> >
> > ie. (in the classpath)
> >
> > /org/foo/fun.library
> > /org/foo/unfun.library
> > /org/foo/MyComponent.jwc
> >
> > Now we have the situation where fun:MyComponent and unfun:MyComponent
> > refer to the same jwc file.
> >
> > "Library namespaces must not overlap"
> >
> > Spindle will not allow library namespaces to overlap. So, what does
> > this have to do with libraries hosted in the context? That case is
> > covered if I modify the above rule like this:
> >
> > "Namespaces of any kind, application or library, must not overlap"
> >
> > That covers libraries in either the classpath or the context.
> >
> > A long winded email for sure but if I list the tradeoffs...
> >
> > TRADEOFFS
> > ++++++++++
> >
> > (1)"Only allow one Tapestry app per project"
> > (2)"Spindle projects must have a, possibly empty, application file"
> > (3)"Namespaces of any kind, application or library, must not overlap"
> >
> > note that I listed another "Use a subset of the lookup rules". #2
> > implies the same thing so I've dropped it.
> >
> > Hmm, only 3 tradeoffs. That's not too bad! I see one more tradeoff on
> > the horizon w/respect to specless page/component classes but I need to
> > get that far in the Spindle effort to describe the reasoning in an any
> > way intelligent fashion.
> >
> > So, everyone on the list has been silent while I've been writing all this
> stuff.
> >
> > Can you live with these restrictions?
> >
> > Have any ideas on what features could be built into Spindle to make
> > them easier to live with?
> >
> > <toungue in cheek>Should I give up as these restrictions so out of
> > line that no one will want to use the tool?
> >
> > 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
> >
> >
> > -------------------------------------------------------
> > 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?cmdlnk&kid3432&bid#0486&dat1642
> > _______________________________________________
> > Spindle-developer mailing list
> > [email protected]
> >
> https://lists.sourceforge.net/lists/listinfo/spindle-developer
> >
>
>


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