How I plan to move forward.

[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?cmd=lnk&kid3432&bid#0486&dat1642