Re: What makes Tapestry IDE friendly?

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 ea=
sier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronim=
o
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> _______________________________________________
> Spindle-developer mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/spindle-developer
>


--=20
The Spindle guy. http://spindle.sf.net
Blog:                  http://jroller.com/page/glongman
Other interests:  http://www.squidoo.com/spaceelevator/


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