comments inline....
On 2/26/06, Howard Lewis Ship <[EMAIL PROTECTED]> wrote:
> My only issue with "the component is the class" is for components,
> especially simple pages, that simply do not have a Java class. This
> is an edge case and, to be honest, if I had to pair up each
>
> HelloWorld.html
>
> with
>
> @Component
> public class HelloWorld
> {
> }
>
>
> I would not loose much sleep. But I also think it should not be
> necessary, if com.myco.myapp.pages.HelloWorld does not exist, Tapestry
> should (at most) emit a warning, and work around that.
>
> I still think, from the point of view of something like Trails, that
> we want the ability to either work around a missing component class,
> or fabricate the component class on the fly. This will take some
> noodling.
Well, a new class, created by hand or by fabrication has a unique
place in the classpath so I think that would satisfy "the component is
the class". The trick and the noodling is to craft a way to associate
the fab class with it's template in way that's not too arcane.
Solving it for the no class case would probably go a long way to
solving the other edge case: "default classes". (Which would make Jeff
happy).
>
> And I still want to stick with the basic premise that Tapestry pages
> are static in structure, and dynamic in behavior. I think that is
> still very important from both a tools point of view, and from a
> runtime efficiency point of view.
Yep, I think T4 strayed away from this enough to cause the grief I'm
having now. And T4's runtime efficency trips a bit on it too. One name
can resolve to mulitple classes but once T4 finds a class, that's it -
there's no chance that other class can play role.
>
> I think we are aggreeing ... page name --> FQCN is the goal, the
> question is how the FQCN can be encoded and abbreviated.
Hooray!
>
> Geoff, what did you think of my "mount points" idea?
I'm going to give it some more thought and respond this evening.
Geoff
>
> On 2/26/06, Geoff Longman <[EMAIL PROTECTED]> wrote:
> > On 2/26/06, Howard Lewis Ship <[EMAIL PROTECTED]> wrote:
> > <snip>
> > > My idea so far has been that we map directly from the path to a page name.
> > </snip>
> >
> > One big problem with Spindle + T4 is that the page name has this
> > special status as the focal point.
> >
> > Before T4 the spec object was the focal point. This was great as the
> > was usually built from a xml file which is a static entity and static
> > entities are what tools have to work with. And files are the easiest
> > thing of all to "find". Allowing for some exceptions
> > (<page>/<component-type> tags) it was a reasonable to infer the name
> > of the page/component from the name of the spec file. Again with some
> > exceptions the class and template "finding" was unabiguous - a spec
> > had one class and one template.
> >
> > In T4 the focus moves to the name a developer uses to reference the
> > page/component. And that focus is completely ambiguous as to what
> > class/template applies. It depends on the context in which the
> > developer uses the name. Tools either have to build a massive map of
> > all possible combinations of name/class/xml/template (most of which
> > are never going to be used) or impose artificial rules to make the
> > task manageable.
> >
> > I found out quickly that IDE users are not interested in more "rules"
> > on the use of the tool.
> >
> > Simply pasting even more rules on top of this inside Tapestry does not
> > go to the root of the problem and only has a minor benefit in tools
> > w/respect to reduced complexity.
> >
> > Turn the focus away from the spec object to another static entity.
> > We've already left xml behind as a possible focus so that leaves only
> > the template and the class. I think everyone would agree that the
> > template is not the right choice which leaves the class. If the class
> > is the 'king' then the spec object becomes a subordinate player as it
> > should be.
> >
> > The fqn of the class becomes the name of the page/component and it
> > just becomes an excercise in allowing developers to use 'simpler
> > names' that map to the fqn. All the pieces are there now to do this.
> >
> > I fail to see why "the class is the page/component" (a poor statement
> > of this concept of focus) is unreasonable.
> >
> > 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
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Jakarta Tapestry
> Creator, Jakarta HiveMind
>
> Professional Tapestry training, mentoring, support
> and project work. http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
