tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geoff Longman" <glong...@intelligentworks.com>
Subject Fw: Need clarification for Spindle
Date Fri, 14 Mar 2003 15:25:10 GMT

----- Original Message -----
From: "Geoff Longman" <glongman@intelligentworks.com>
To: <tapestry-developer@lists.sourceforge.net>
Sent: Friday, March 14, 2003 10:18 AM
Subject: Re: Need clarification for Spindle

> > 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
> even if the
> 'one per' restriction were maintained. In other words, enough work has to
> 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
> 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
> 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
> 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
> 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
> 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
> right way this time.
> >
> > Geoff, please do not take offence or anything
> none taken.

View raw message