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