From: Martin D. <ma...@pa...> - 2002-01-30 17:45:41
|
Hi Ian. First, thanks for your FFK library! We've been using FFK with our Webware projects over the last 6 months or so. It works. We are experiencing a recurrent frustration, however. It's hard to explain, but to us your solution to hooking FFK into running servlets seems unorthodox from a Webware perspective. This seems to be causing us confusion whenever we revisit our FFK-enabled servlets. Can you clarify for us why you integrate FFK by overwriting output methods, rather than having it do its thing in awake()? Is there some subtle benefit that we're overlooking? (This may just be a confusion of different methodologies. We try to keep "stuff that builds state" in awake() and keep "stuff that makes html" in outputXXX() methods.) Another question: have you considered adapting FFK so that it can -- when appropriate -- produce XHTML compliant tags? It would be nice if FFK could read the self.writeDocType() or something to determine what kind of tags to build. The actual requirements for adding XHTML tag support to FFK are pretty simple. For XHTML, - replace use of tables with divs in compound field classes - make sure all tag attributes are quoted - eliminate use of tag attributes that are deprecated in XHTML - close all one-off tags, such as <br /> and <img /> and <input /> The main question would be the "preferable" way to implement it, be it by alternate methods or some sort of tag dictionary look-up. What do you think? Martin Doudoroff & Matt Feifarek |
From: Ian B. <ia...@co...> - 2002-01-30 20:01:13
|
On Wed, 2002-01-30 at 11:46, Martin Doudoroff wrote: > First, thanks for your FFK library! We've been using FFK with our Webware > projects over the last 6 months or so. It works. > > We are experiencing a recurrent frustration, however. It's hard to explain, > but to us your solution to hooking FFK into running servlets seems > unorthodox from a Webware perspective. This seems to be causing us confusion > whenever we revisit our FFK-enabled servlets. Can you clarify for us why you > integrate FFK by overwriting output methods, rather than having it do its > thing in awake()? Is there some subtle benefit that we're overlooking? (This > may just be a confusion of different methodologies. We try to keep "stuff > that builds state" in awake() and keep "stuff that makes html" in > outputXXX() methods.) As I've been using awake() more myself, I've also recognized this problem. I haven't thought of any good alternative, however, because FFK needs to be able to render as well as process. In the case when someone submits an invalid form, FFK needs to intercept that and go to the method that writes the form -- it can't be overriding awake() at that point. If it is valid, FFK needs to redirect to some method based on how it was submitted. Anyway, I guess FFK could override awake(), but it would still have to override some rendering method as well. That just seems more complicated, without having changed anything significant. So while I'm not terribly excited about how FormServlet works, I haven't thought of anything better yet. One thing I think I want to change is to use more default naming, so setting up a form is easier as long as you do it conventionally. > Another question: have you considered adapting FFK so that it can -- when > appropriate -- produce XHTML compliant tags? It would be nice if FFK could > read the self.writeDocType() or something to determine what kind of tags to > build. The actual requirements for adding XHTML tag support to FFK are > pretty simple. For XHTML, > > - replace use of tables with divs in compound field classes Why's that? It seems like divs would be hard for minor layout -- actually, there's no fields that use tables anyway. .htFormTable() is just a convenience function. If there's other ways of doing basic layout, then they should just be different functions. > - make sure all tag attributes are quoted That would be fine for all fields. > - eliminate use of tag attributes that are deprecated in XHTML Are there particular ones you are thinking of? > - close all one-off tags, such as <br /> and <img /> and <input /> This is the only place that seems weird... I suppose browsers generally don't care. I guess it would be fine, since I can't think of any real negative. > The main question would be the "preferable" way to implement it, be it by > alternate methods or some sort of tag dictionary look-up. What do you think? Externally, the cleanest way seems to be making XHTML-generating subclasses. Otherwise, it should be passed through the options dictionary -- potentially FormServlet could automatically add that option by looking at the doc type. Ian |