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: Steve Quirk <email@hidden>
- Date: Fri, 16 Feb 2007 08:15:38 -0500 (EST)
=====================================
From Bill Bumgarner <email@hidden>
Date: Tue, 6 Jul 1999 20:27:30 -0400 (EDT)
!^^^^!
Ha! What was true in '99 is still true today (paraphrasing from
Bill & Ted's Excellent Adventure). The other thing that hasn't changed in
that time is WOBuilder.
Seriously - use Eclipse/WOLips or something before bad habits (and bad
html) fester.
And yeah - Xyle scope rocks!
- steve
---
On Fri, 16 Feb 2007, Jerry W. Walker wrote:
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