On 5/10/06, Martijn Hinten <[EMAIL PROTECTED]> wrote:
 I have been wondering this for some time now: Is it the general consensus
to get rid of .page files and do all binding in the html (and injection via
annotations in the java classes)?


I think it depends on the size of your team and complexity of your
app.  With a fairly large team, including one person devoted to
layout, I prefer to keep all component declarations in .page files, so
that the layout templates are as clean as possible and least likely to
get screwed up by someone making edits without a clue about how
tapestry works.  I've generally got nothing but jwcid attributes in my
templates.  A simple macro in just about any editor will make it easy
to switch between .page and .html files in a single keystroke or mouse
click, so the complaint about having to switch files really isn't
valid, to my mind.

We also attempt to keep components in the same order in the .page file
as they are used in the .html template.  It is a couple of minutes of
developer time per page at the end of any release cycle on any pages
that have gotten out of whack and it keeps things easy to find.  In
fact, I have a macro in vim which will switch to a .page file and go
to the same location as I am currently at, as a percentage of the file
length, with two keystrokes.  Odds are usually good that I can see the
component that I am looking for as soon as the other file is visible,
and both files are so much more readable as a result.

The only thing I hate is when informal parameters are important to the
function of the component, since, as far as I know, they must appear
in the html file.  I really wish there were a way to bind informal
parameters to a component from within a .page file, overriding any
informal parameters of the same name that are in the .html template
which may be necessary for layout in the unrendered page.  That way, I
could put ALL of my parameter bindings in the .page file.

--sam

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to