Let me co-opt this discussion and talk about me. me me me me me. :-)
From the Spindle perspective, I have to work backwards from something
to everything else.
Backwards in that Tap the runtime starts with a request for a page,
and goes from there looking for specs, finding classes, instantiating,
setting up, rendering etc.
I start with a project full of files. There is no request.
To discover all the pages in the app, I parse web.xml and find the app
spec parse it, validate it and then parse and validate a possibly long
chain of library namespaces too.
This gives me a tree of namespaces. These are the first things that
"anchor" me in the Tapestry world.
Then I recursively resolve each namespace, collecting up all the page
and component specs, using explicit declarations, lookup rules, and a
process of elimination to get all of these. Each spec I find is a
little 'anchor' for an individual page or component. I call these the
anchors as each spec refers to exactly one page or component. It will
never be the case that two pages share the spec. (yes you can bind two
names to one spec using a <page> tag but it's really the same page)
The class hangs off the spec (or is a default) and once determined the
class never changes.
la la la la .. eventually a model of the whole app is discovered and
created. And there is an strong chain of spec -> class -> template
T4 has broken me in that a) specs are optional b) class finding is now
quite tied to runtime behaviour c) it's pretty easy to have the same
'name' refer to different specs and/or classes (and even namespaces!)
depending on the context of the runtime request.
There are no anchors anymore.
Doing away with the xml (we're talking about .page and .jwc here - not
.application and .library) is fine with me as long as I still have an
anchor. If the class is the only anchor left:
1) Classes for pages and components must exist in only one Tapestry
namespace - I have suggested a strategy for this - it's yet another
annotation to declare namespace membership. Subclassing does allow
reuse across namespaces of course. No explicit ns decl would imply the
application namespace. Although that breaks down in the case where
multiple Tap apps share a war but Spindle never supported it anyways.
2) A strong link between the class and the template must be feasible.
Strong in that regardless of the context, one class, one template.
(skin happy people will scream but this is maintaining the status
quo). I don't know how this will work in the specless world of T5
3) The page/component is the class and the class is the page/component
- in other words pages and components don't share classes - with an
allowance for the case of a bunch of "specless" templates sharing a
class (specless in the T3 sense) - but that's a corner case. treat it
as the exception and not the rule and I can deal with it.
4) The same name for a page or component must always refer to the same
class, regardless of the context of the request. Also, by whatever
mechanism is implemented to have "names with paths", whatever names
are used, if it resolves to the same class, it's the same
page/component in the same namespace!
I think that makes the class a sufficent anchor.
Oops I forget one thing. Each class should have a mandatory annotation
(not inherited) that declares Hi! I'm a page (or component)!
Now I have the framework needed to do the backwards hop. Get those
namespaces and then just lookup all the classes with the explicit (not
inhertied) annotations and voila I have all the namespace and all the
pages and all the components. connect all those classes with their
templates and any templates left over are the ones I mentioned in #3.
Now is this an argument for or against nuking the specs in T5? Not
really. I'd like to see the specs hang around as in a subordinate
role. Dropping from the importance they formerly held to the same
level of importance as the .properties files for I18N. The xml is
there if you want to use it to get the cruft out of the template or
override a class annotation. But the class is the page or component,
it is found first and an xml spec would no longer play a role in that
lookup.
Plus I think one can do away with many of the complicated and error
prone "lookup" rules that Tapestry has.
Look at Rails - configration by convention. Tapestry is cool but there
are few real conventions and many ways to circumvent them.
Geoff
On 5/17/06, Brian K. Wallace <[EMAIL PROTECTED]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I wasn't going down the "should we have it or not" road. I've heard of
the nuisance, and I've heard the joys of it. I was just basing my
question on what I had pieced together (aka: read - not sure how that's
really piecing it together... but) and wondered if there was an answer
to the hole I saw remaining in that train of thought.
To jump ship and play devils advocate for retaining XML, I pose two
questions:
Question: Have you ever edited HTML code?
Answer : Sure - who hasn't? (I know - those who can get by with
WYSIWYG editors)
Reason : You can't get the look you want without editing HTML code
It's easier/faster/works cross browser/etc
Question: Have you ever NOT edited your XML code?
Answer : No. How could I make changes to it without editing it?
Proposition: Take a 20 page Open Office document and change a single
word on page 10. Did you do it by editing the XML code directly?
Difference? Structure and tooling. This is where I believe XML has
been let down - as opposed to the other way around. Look at a site.xml
in Eclipse - two tabs, two views - the "what XML?" view, and the "oh,
THAT XML" view. Same with build.properties, plugin.xml - provide a way
to do what needs to be done in XML without coding XML and you keep tools
progressing and the majority of users (the ones using IDEs) happy.
Take the "simplistic" approach - only supply view one with "what do
you want to do" buttons and you get a lot of people saying it's not
powerful enough. Take the "XML-direct" approach - only supply view of
XML directly and you get "it's too complicated". Supply both and, while
you still get those, you can say "then don't click here".
Back on ship now. :-)
Again - not proposing one way or another. Just trying to fill in my
understanding of the current direction.
Brian
James Carman wrote:
> I, for one, do not agree with getting rid of XML altogether. There
> needs to
> be a way to support both. It should be abstracted. Why not create an
> abstract metadata facility which allows you to plugin MetadataProviders?
>
> On 5/17/06, Geoff Longman <[EMAIL PROTECTED]> wrote:
>>
>> Valid point - how is that different from today?
>>
>> If our designer chnaged the file structure layout of the templates
>> we'd be screwed. Actually we would not let her do it.
>>
>> While it's great that designer and developer don't trip over each
>> other in Tapestry land there has to be *some* mutual understanding on
>> these issues before something flies over the fence!
>>
>> Geoff
>>
>> On 5/17/06, Brian K. Wallace <[EMAIL PROTECTED]> wrote:
> I've been looking around trying to mesh two parts of Tapestry and T5
> comments together - hopefully I'm missing something somewhere.
>
> A stated design of T5 is the negation of page and jwc files -
> Annotations rule the day.
>
> With that in mind, where is the connection from HTML to Java? Or will
> there only be a connection from Java to HTML?
>
> Scenario:
>
> Designer mocks up a site with the following structure:
> index.html
> blah.html
> secure/
> index.html
> account.html
>
> This is then approved and thrown over the wall to the developers to
> integrate into their "back end" with the following package structure:
>
> com.company.tapestry
> com.company.tapestry.pages
> com.company.tapestry.secure
> .
> .
> .
>
> - From what I've gleaned from the T5 discussions, after taking into
> account "no more page files" and "no more jwc files", I don't see how
> the designer could change the layout of the HTML without a recompile of
> the Java code to support the changes. With XML, it would require
>>> changes
> to configuration, but without them? Am I missing something obvious? Or
> is this the "reduce flexibility" that mandates "you start with this
> structure, we map it to package structure appended to your stated
> 'starting point' - period."? For example:
>
> .application
> <meta page-classes = "com.company.tapestry"/>
>
> index.html == com.company.tapestry.Index
> blah.html == com.company.tapestry.Blah
> secure/
> index.html == com.company.tapestry.secure.Index
> account.html == com.company.tapestry.secure.Account
>
> [curious to know if this is the plan, or if it's the Java annotations
> defining the mapping]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
iD8DBQFEa3xlaCoPKRow/gARAi19AJ92fKQofr0lc28z3yrxdcrtjxwsFgCgpLu5
6H6e+Y1bjaagQspNPHHry0o=
=QB+C
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
The Spindle guy. http://spindle.sf.net
Blog: http://jroller.com/page/glongman
Other interests: http://www.squidoo.com/spaceelevator/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
