I've been familiarising myself with the source with the aim of creating an
XHTML/MP site for WAP 2.0 mobile phones and that pass the W3C Mobile OK
tests. At this time I do not believe that there is a need for a WAP 1.0
(WML) interface to Laconi.ca.
In order to do this I think the code needs some restructuring. In particular
the classes in lib. As I am still familiarising myself with the code I
though it would be good to start a discussion on my thoughts.

A WAP 2.0 web site will have a different page and site structure. It will
also need to generate XHTML/MP rather than HTML.

In order to do this laconi.ca needs a class that is a similar to
HTMLOutputter but that creates XHTML/MP compliant output. I don't think that
this should be done by scattering if's throughout HTMLOutputter. It's not
good class design and doesn't enforce the need to have different Actions for
different outputs. The obvious solution would be to have an XHTMLOutputter
as well, but there is a complication.

The Action class subclasses HTMLOutputter yet contains function
implementations and prototypes that should be generic across both XHTML/MP
and HTML actions. Duplicate such code in two parallel classes i.e an
XHTMLAction and HTMLAction would be just wrong. It looks like Action is the
only subclass of HTMLOutputter and I cant see anything that directly creates
an HTMLOutputter. I think this can be resolved by inverting the existing
class hierarchy.

Instead of Action extending HTMLOutputter it would extend XMLOutputter.
Generic functions would remain and page structure calls (e.g. showBody())
made into prototype functions. There would then be two subclasses HTMLAction
and XHTMLAction that would implement generic page structure and markup
functions.

All XHTMLActions and associated classes could be put in their own
subdirectory with the existing actions subdirectory remaining for HTML
specific ones and all current Actions subclassing HTMLAction instead of
HTMLOutputter.

There's a further complication in the way that errors are currently handled.
Sometimes an error will generate a Client or Server Exception and in other
cases an ErrorAction class is created and invoked directly. These all
produce HTML output which would no longer be acceptable. Would there be a
problem in changing all errors to throw exceptions that can be caught in
index.php where an Error Action appropriate to the required output type
could be created?
_______________________________________________
Laconica-dev mailing list
[email protected]
http://mail.laconi.ca/mailman/listinfo/laconica-dev

Reply via email to