Re: How are you handling html templates created in other apps?
Re: How are you handling html templates created in other apps?
- Subject: Re: How are you handling html templates created in other apps?
- From: "Jerry W. Walker" <email@hidden>
- Date: Fri, 16 Feb 2007 01:44:46 -0500
Hi, Kevin (and Steve),
On Feb 15, 2007, at 10:14 PM, Steve Quirk wrote:
For the love of all that is holy, stop using WOBuilder. As you can
see, it messes up HTML. So stop it.
Just use a text editor.
- sq
(Sorry - I'm just tired of inheriting projects with gigabytes of
crappy WOBuilder-laden broken html).
With all due respect to Steve (you ol' curmudgeon), sorry, but I have
to weigh in on the other side of this issue. And if I have to weigh
in against a heavyweight, I have to weigh in heavily, so kick back
and enjoy...
I think that everyone can agree that there are things that are broken
about WOBuilder. However, the breakage in WOBuilder seems to pale in
comparison to the breakage I see in other tools that are supposed to
help one design (generate) a web page. Particularly so when it comes
to generated HTML garbage.
I use WOBuilder all the time, but I use it as an aid, not as the only
game in town. There are definitely things that are more easily done
with a simple text editor than with WOBuilder, but the opposite is
true as well.
When given a page created by some web designer with a tool like
Dreamweaver, the first thing I do is make a copy of the exact file I
was given and stash it somewhere safe, both to CYA... well... CMA,
and to use as a definitive statement of where I started when things
get very confused later. Then I generally take the following steps:
1. open the working copy of the page in a browser and get it to
work correctly, generally with the designer present if possible. That
is, determine that it is rendering the page in the way the designer
thought it was supposed to in at least one real browser as a
standalone HTML page. In this step, Safari can help you check to
confirm that all the referenced resources are successfully loaded
(check the Window->Activity menu item), or, if not, which ones are
missing and where to look for them. While it's still early in the
game, you might also use Safari's JavaScript console to confirm that
the JavaScript is working as planned. To figure out how to get Safari
to display its JavaScript console (and some other useful tools) go here:
http://developer.apple.com/internet/safari/faq.html#anchor14
2. Open the page in at least one other browser as a quick check
that the designer has not designed for only one browser. Get it to
work again as ostensibly designed if it doesn't do so. (Of course, if
you're a hot enough developer resource, perhaps you can insist that
the designer undertake these two filtering steps before you have to
get your hands dirty. Then again, maybe not.)
3. Once the page is obtaining all its resources and working from a
visual standpoint, it is usually worthwhile (in the sense of saving
you untold hours later) to run it through an HTML checker to check
for correct HTML. There are several tools to help you do this, but
the one I've been using recently is the free Mac browser out of
Germany called iCab by Alexander Clauss.
http://www.icab.de/
If you display a page in iCab, a little face shows at the top of the
window between the browser's address field and the Google search text
field. If the face is green and smiling, all is well. If it's red and
frowning, there are HTML parsing errors in the page and by clicking
on the face, a list of all the errors is displayed. By double
clicking on an error message in the list, iCab will display a window
containing the page source with the error highlighted.
I don't get compulsive about correcting all the HTML errors.
Sometimes there are just too many to deal with, but I do correct the
most egregious ones, like cells missing in table rows, and the
simpler ones, like unbalanced tags. I find it's best to focus on
structural errors.
4. Then I start up Quirk's beloved WOBuilder and create a new
WOComponent. I switch to Source view and copy the entire page,
intact, into the HTML pane of WOBuilder's window. Then I copy out any
scripts (e.g. JavaScript and such) into a text file to keep them from
being munged by the next step. In particular, I copy from the
<script> tag through its balancing </script> tag inclusive. You might
ask why I don't just use the original page that I saved for that...
Nope. I do everything in my power to keep that sucker from any
accidental changes. It's my backup, not a working document.
5. While still in Source view on the page in WOBuilder, I do a
Find/Replace ALL looking for any instances of concatenated tags (i.e.
instances of "><") and replacing those two characters by the sequence
">\n<", where "\n" represents a new-line character.
6. I then have WOBuilder reformat the result. Perhaps there are
other tools that will properly indent HTML, maybe even do a better
job, but I generally use WOBuilder for that.
7. WOBuilder's reformatting will usually munge the embedded
scripts and often make them unusable, which is why I copied them out
in the first place. So I replace the newly munged scripts with the
copies I made in step 4.
8. I take the reformatted page with the scripts restored to their
original form, once again render it in a web broswer and compare the
rendered result with the original page rendering. Although browsers
are supposed to ignore how much white space there is between elements
(that is, they shouldn't distinguish between a single space and
several spaces, tabs and blank lines), they can get picky about it at
times and sometimes get downright antagonistic.
9. Fix as many of the differences as you can without screwing up
the formatting, then bite the bullet and push some stuff back
together, if that's what it takes. Browsers are better about that now
than they used to be, and CSS can go a long way in making the
rendered page immune to reformatting. In any case, you should now
have a very usable HTML page for introducing webobject tags... even
if you use Steve Quirk's approach. :-)
10. You've already got the page open in WOBuilder, so now you can
save it as a WOComponent into your project, which will connect it to
Xcode (if you're using that combination) and generate your .wod and
Java files. If you're using the Eclipse/WOLips combination, then you
need advice from someone else at this point.
11. I switch back to WOBuilder's Layout view and start replacing
things in the page with dynamic elements. With complicated pages, I
generally find this easier to do than trying to work with straight
text editors, even when the HTML is formatted. I have no compunctions
about switching to Source view quite often to tweak things that are
hard to do in Layout view, but I find Layout view to generally be my
friend.
12. My style of working at this point is generally to do most to
all of the replacements of static HTML elements with dynamic elements
before trying to do anything with the Java. A rendered HTML page is a
visual medium, so I try to do the work with visual tools and find it
hard to understand why others would work strictly with text tools to
do the same job. But, hey... different strokes...
13. Once the bulk of the dynamic elements are in the page, I start
creating keys in WOBuilder to bind to the dynamic elements. This is,
of course, the inverse of the advice that Chuck Hill gave you, where
he depends on code completion. By creating the keys in WOBuilder, I
know that the exact same key is being declared (automatically) in my
Java file with the appropriate type. Code completion can do almost as
good a job, but there is still a bit more room for error there.
At this point, the process becomes a lot less algorithmic and tends
to depend on what you're trying to accomplish with dynamic elements.
I find the Source view of WOBuilder quite usable as a text editor
when the page is reasonably well formatted. I use it a lot, but also
go back to layout view quite often for complex pages to stay
oriented. This becomes important with complex table structures.
If your designers don't use HTML tables but have moved to CSS to
organize and format their pages, then I would recommend a tool I
recently found called Xyle scope. It will render a page like a
browser, but will help you navigate through the HTML hierarchy and
the related CSS cascade to easily find exactly which CSS property
from which part of the CSS cascade is affecting a given HTML element.
It's easily worth the $19.95 USD that they're asking for it. You can
find it at:
http://culturedcode.com/xyle/
Finally, for all the good it will do, you might ask your designers to
try to make your job a bit easier. My friend, Bill Bumgarner, wrote
an internal draft document back in 1999 with some advice that's still
worth while. I'm attaching a copy, pretty much in his words, but
edited to remove things that no longer apply and things that were
directed at a purely internal audience.
Remember, HTML was a bit more primitive and there was no CSS when
this was written.
Hope this helps.
Regards,
Jerry
=====================================
From Bill Bumgarner <email@hidden>
Date: Tue, 6 Jul 1999 20:27:30 -0400 (EDT)
To: XXX
Subject: HTML Design Guidelines
Unfortunately, we haven't had a chance to truly formalize a set of
guidelines for how HTML/Images should be delivered such that they
smoothly integrate with an applicaiton development environment.
However, we have had some rather tedious experiences as to what kinds
of decisions can be made that make application development
significantly more difficult or costly.
A tool that has greatly assisted us in dealing with HTML is an HTML
syntax checker. They tend to do an excellent job of detecting
structural problems (mis-nested <TABLE><TR><TD> tags, tags that
aren't closed, and other errors) that may not cause a visual problem
but can really trip up HTML processors like the ones used in various
middleware solutions (like WebObjects).
This was a bit rushed in that I wanted to put something together that
covered the big ticket items in time for the meeting tomorrow. There
are more, but I think these really cover the Big Nasties that have
cost us a lot of time/effort/frustration over the years....
(1) The HTML should be well structured.
Most browsers can deal with a number tags being closed by
implication. i.e. a table cell lacking a </TD> will be effectively
"closed" by the browser by a </TR> tag.
However, the HTML template parsers in middleware packages typically
need to process the HTML to determine some limited amount of
structure (mostly to determine form membership).
Typically, the middleware parsers are a lot less forgiving about HTML
structure than a browser is. As a result, it greatly assists in the
conversion from HTML mock up to middleware template if the HTML is
"well structured". This simply means that tags are closed in the
reverse order with which they were opened.
Example:
<font ...><b>This is <i>Good</i>.</b></font>
Vs.
<font ...><b>This is <i>Bad.</font></b></i>
WebLint (mentioned above) goes a long way to ensuring that HTML is
properly structured. HTML should pass through WebLint and generate
virtually NO warnings or errors.
Some HTML creation tools do not necessarily generate well structured
HTML.
---
(2) Page structure should be highly consistent-- the same-- across
pages that look the same.
If two pages are structured the same-- both have a logo/search area,
the category nav content, and the nav bar across the top-- the
underlying HTML should be structured exactly the same.
That is, the HTML for the navigation section on both pages should be
structurally identical.
If the HTML site mock-ups can be delivered as server side includes,
it would be ideal. That is, if each page that has a nav bar is able
to ss-include the same hunk of HTML and look correct, then this will
make conversion to an application server environment (with reusable
components) a lot less costly/time-consuming.
If a particular component's content changes throughout the site-- a
nav bar loses/adds links depending on the context of the user's
interaction-- then that content change should be done in such a
fashion that it doesn't require changes to the structure of the
surrounding page.
---
(3) Stick lots of comments throughout the HTML!!!
They don't cost anything in the end product. The middleware package
will rip 'em out of the templates automatically and will not send 'em
on to the client as a part of the dynamically generated HTML string.
As such, they can be used to document start/end of various sections
of the structure, formatting issues, etc...
---
(4) Consider how error messages and other user indicators should be
displayed
We have never worked with a client that has provided us with HTML
that has actually had error display in the user interface definition!
The error display can be done on a separate copy of the page or it
can be done in-line using comments and we can easily pull it out and
make the dsiplay of it conditional in the component templates.
.... </TD></TR> <!-- Error stuff displayed when user screws up search
--> <TR><TD COLSPAN=2><FONT COLOR=RED> The search for <!--keyword-->
yielded no results. Try decreasing the number of criteria. </FONT></
TD></TR> <!-- End Error Stuff --> </TABLE>....
Alternatively, you can make up your own tags for surrounding the
error stuff. Like: <ERRORSTUFF User Screwed Up Search>...errror
content...</ERRORSTUFF>
---
(5) When mocking up table or other repetitive output, consider all
possible styles of display.
When converting between an HTML template and a set of middleware
components, it isn't terribly useful to see the same content repeated
X times.
Instead, the developer needs an example of all possible ways data may
be displayed; what should be displayed when a particular field or
element is blank? If doing a grid, what should be displayed in cells
that have no corresponding item?
When doing displays that may have a next/previous, more buttons, or
multiple pages of information display, it is important to provide a
definition of how it should look when there is more information (in
either direction) or when the display is contained entirely on one page.
---
(6) Consider how the dynamic nature of the end product might
influence look and feel.
We frequently receive HTML mockups that look just fine until
dynamically generated content is plugged into the templates. Maximum/
minnimum word lengths change, the number of rows in a table might
change, the number of items in navigation content may change or be
dynamic, etc...
All of theses things can break content that has specific look/feel
limitations associated with the content.
Invariably, there will be situations within which their will be
display limitations. Document these limitations through the use of
comments (3) or a separate document describing the features and/or
limitations of a particular display.
=====================================
On Thu, 15 Feb 2007, Kevin Windham wrote:
I have a template someone designed for me using Fireworks/
Dreamweaver. If I cut and paste the HTML into WOBuilder, a lot of
stuff is broken. There are rollover buttons using various
javascripts with preload stuff, and various other things that are
just messed up, and I'm not sure where to look for info on how to
handle this sort of thing. I could try and recreate the layout
from scratch using the graphics included in the template, but I
think that will not be a good way to work all the time.
Is there any primer out there on how to handle this issue?
Thanks,
Kevin
--
__ Jerry W. Walker,
WebObjects Developer/Instructor for High Performance Industrial
Strength Internet Enabled Systems
email@hidden
203 278-4085 office
--
__ Jerry W. Walker,
WebObjects Developer/Instructor for High Performance Industrial
Strength Internet Enabled Systems
email@hidden
203 278-4085 office
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden