Re: What makes Tapestry IDE friendly?

Although I'm sure you'd look great in a Swami hat, I agree that tooling
shouldn't require it.

I actually went through the [T5] mail, as well as your Wiki page about
T4 issues/possible solutions/scenarios and the archives on here before
sending that last message. I had "no ambiguity" as #1 - now I have a
reference word "anchor" to put with it when I head over to tap-dev to
see if there's been any more written/thought up about how the whole
thing CAN be 'anchored'. Spindle was very well received by my main T3
and, without knowing all the details of why it wasn't there for T4, were
glad they were on T3 when they saw it wasn't "there" for T4. [on that
note - a personal Thank You for all your work getting it there for T3!]
I'd like to make sure we can get back to making more tooling possible -
not less.

Brian

Geoff Longman wrote:
> What makes Tapestry IDE friendly is when the tenet "static in
> structure but dynamic in nature" is held to.
>
> There needs to be an 'anchor', something about a page that is a)
> always there b) never changes
>
> what I mean by "never changes" is that the anchor is a file, and the
> same file regardless of how a page or component is referenced by name.
>
> In Tapestry before T4, the xml spec was the anchor. The spec defined
> the class and that class never changed. I could discern every page and
> component in the application by either looking for explicit
> declarations or by implementing my own version of the "lookup rules"
>
> Naming didn't come into play as the spec name was the name of the spec
> file, or it could be overridden explicitly in the static namespace
> spec.
>
> So, there was only one way to address a page or component by name and
> that name always referred to the same spec file and class.
>
> No ambiguity.
>
> T4 threw all that out of the window with:
>
> 1) Specless pages and components (optional)
> 2) Page names with path parts
> 3) org.apache.tapestry.page-class-packages
> 4) org.apache.tapestry.component-class-packages
>
> 1 and 4 are less painful
> 2 and 3 were the killer.
>
> Now a page could have a different class depending on which name it was
> referenced by. The entire static nature of the application is lost.
>
> Even worse is that the implementation of T4 itself did not take this
> into account as the class is found/loaded only once.
>
> It easy to come up with scenarios where someone references a page by a
> name that, when combined with org.apache.tapestry.page-class-packages
> results in no class being found and so the default,usually BasePage,
> is assigned. More often than not this is not the intention of the
> developer and the application is broken.
>
> Once the bad decision has been made there's no going back. The page is
> in the pool and even if the correct naming is used subsequently that
> instance is broke for good. Worse, Tapestry remembers the bad class
> decision by storing it into the specification object, thus repeating
> the mistake again and again until the application is restarted.
>
> So you have a situation that a bad page might get into the pool,
> wrecking the app for all users.
>
> But back to IDE tools. If the structure of the app is not static it
> becomes an impossible task to build a tool that will work. I tried to
> cover this by trying to figure out what all the possible combinations
> were but it's like trying to force static typing on top of a dynamic
> language like Perl by guessing ahead of time what types *might* be
> assigned to a variable.
>
> Many of the possibilities are rare but it's impossible to "read the
> developer's mind" and pick the ones they won't use.
>
> Since day one I've stated that I'm not going to go down any road that
> requires me to don a Swamy hat!
>
> But I did try anyways, for months and months without any progress.
>
> There are long diatribes on this in the archives for this list.
>
> As for the current plans for T5, of course it means a rewrite. Every
> major version of Tapestry since 2.0 has meant a rewrite. I'm not happy
> about it but I can live with it as long as the framework at least
> makes it possible to do a rewrite.
>
> Losing the xml altogether means there has to be a new anchor, the
> class. I've already made my thoughts known on this on the tap dev list
> (look for messages with [T5] in the subject).
>
> In short, and in selfish language, I want each class that represents a
> page or component to have an annotation. One class, one
> page/component. period. The package of the class defines the "lookup
> namespace" of the page/component. So the true name of the
> Page/Component is the fully qualified name of the class.
>
> Meta's like
> org.apache.tapestry.page-class-packages
> org.apache.tapestry.component-class-packages
>
> lose their "lookup" role and become simply mechanisms to "short form"
> a long FQN. (although I'm not sure if this will still cause problems)
>
> Names with path parts can still be there but pay a lesser role.
> Without any "short forming" the path name of a Page/Component would be
> the FQN.
>
> Obviously there is still the case that people want to preserve where a
> bunch of templates can "share" a class - I think this is a corner case
> that can be handled outside of what I have described.
>
> I'm popping out now to continue adding warnings in Spindle 4T4 for
> naughty T4 "features" Spindle won't support ;-)
>
> Regards,
>
> Geoff
>
>
> On 5/16/06, Brian K. Wallace <[email protected]> wrote:
>> Geoff / Hugo -
>>
>>   This relates back to a statement Geoff made a while back regarding
>> "ensuring T5 is ide 'friendly'".
>>
>>   The current presumption would be complete removal of all page/jwc
>> files leaving only annotations. If this is the case, will the work
>> currently underway be usable in any form or would it mean another
>> rewrite? I remember concern about IDE integration with only annotations
>> on the tap-dev list, and I admit to not searching too long for an update
>> on that. From what I've seen/read, I'd believe the IDE specific pieces
>> would be ignorant of where/how errors occur (which would be good), but I
>> also believe the 'common piece' would be drastically affected.
>>
>>   To make sure we end up in the "right place", what do you see as being
>> necessary to allow IDE support as a first class citizen in Tapestry? (if
>> not for Spindle/TapIDEA of today, then a 'new' one of tomorrow)
>>
>> Brian
>>
>>
>> -------------------------------------------------------
>> Using Tomcat but need to do more? Need to support web services,
>> security?
>> Get stuff done quickly with pre-integrated technology to make your
>> job easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache
>> Geronimo
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>> _______________________________________________
>> Spindle-developer mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/spindle-developer
>>
>
>


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642