[Tapestry-developer] Re: Need clarification for Spindle

[Geoff L. <glo...@in...>]

> Hi Geoff,
>
> I would like to start off with complimenting you on a splendid piece of
> Spindle work.

Why thank you!

> Started using it when 2.4 came about with implicit stuff so I had to
> stop using it (unfortunately).

I know. its a pain, working to rectify!

> Being aware of the fact that I have not had a chance to contribute to
> Tapestry yet I would like to share some of my thoughts though.

comment is always welcome!

> In Xtreme Programming the adagium 'First make it work & than make it
> fast' is key. Looking at my own experience (20y) I could not agree more.
> If one takes this into consideration, combined with the fact that time
> is irreversible, it might not be altogether horrible if Spindle could
> (for the time being or forever) only handle 1 app/ lib per Eclipse
project.
> One can very easily create the illusion of working with different apps
> (see workbench). So what if one has 3 Spindle apps in Eclipse instead of
> 3 apps in 1 project, who cares? Don't like it? Don't use it!
> The product is great in its own right.

I understand. And that was exactly the thinking when the original
restrictions were applied.
The landscape has changed though with Tapestry 2.4. To support implicit
components and
the new locations for things Spindle has to do the work I described anyways,
even if the
'one per' restriction were maintained. In other words, enough work has to be
done to support the new stuff that
it won't be a big deal to drop the 'one-per'.

>
> If someone were to ask me I would suggest that getting it up to 2.4
> speed would be far more benificial to current and esp. future Tapestry
> users.

The approach is to build the core functionality described (hence
spindle.core) then give enough
added value that even without the GUI stuff it still makes it easier to
build Tapestry 2.4 apps.

An example, the core builder should be able to mark as errors things like:

- a page references a component (say contrib:Pallete) but the contrib
library has not been added
- an application file references a non existent component
- an application file references a missing library file
- web.xml defines a servlet X, which is a sublcass of ApplicationServlet,
but the value returned in the overriden
  method, getApplicationSpecificationPath can't be resolved to a
.application file
-web.xml defines a servlet Y, (ApplicationServlet) but the init-param
org.apache.tapestry.application-specification can't be resolved.

etc.The list can go on and on. I think that even if one had spindle.core and
text editor, developers would be ahead of the game!
Runtime Tapestry stops at the first error. spindle.core should be able to
present all the errors at once, without
starting a Tapestry runtime!
Gui support in the form of wizards and editors will make it all complete but
spindle.core would still have value.

> Unless you need it desperately for yourself, what would be the % of
> people who do 1p:1s vs. 1p:ns (80%+ ?)?

That's what I'm trying to determine, would it outrage the community if
spindle.core treated as an error
something that Tapestry allows? (I shoulda been more precise). IMHO tapestry
allowing these kind of things is
just giving developers enough rope to hang themselves. I'm not suggesting
that tapestry change in any way,
but spindle.core flagging these as an error could help resolve what I
believe could raise cases that confound
developers.

Consider:

In a war, two applications (A,B) refer to the same .page file X, A and B
both each define a component with name 'C' but each is its own .jwc file and
has its own, different, parameters. X includes a component called 'C'. At
runtime 'C' is resolved to a different component depending on whether the
call is in A or B. How does spindle resolve the parameters? from A or B?

At runtme this could raise confusing scenarios if X was built to use A's 'C'
parameters. Then application A's X page would work but application B's X
page would fail with an exception.


> I am aware that this does not answer your Q in any way but ...
> A couple of days ago a mate of mine pointed something out to me re. the
> platform I am working on (Tapestry is going to be resp. for the UI) & he
> showed me that it would be more efficient for me to focus on a high
> impact area (which I considered just average before the chat). Stepping
> back I looked at it again and he was right.

Sure, and spindle.core will evolve too. High priority stuff first (like
finding things), then basic error checking/marking,
then, more complicated dependency related stuff, then incremental builds.
The output from the builder will be the input to the GUI stuff. The
underlying infrastructure for the old spindle was somewhat add-hoc (I knew
zip about Eclipse when I started) and couldn't handle 2.4 without changing
it so much that it was an infrastructure rewrite anyway. So, I'm starting
fresh, using what I've learned building Spindle the first time to do it the
right way this time.

>
> Geoff, please do not take offence or anything

none taken.