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
|
