[daisy] PHP Framework week report

Wed Aug 9 17:23:01 CDT 2006

Hallo!

2006/8/9, Bruno Dumon <bruno at outerthought.org>:
> On Wed, 2006-08-09 at 22:16 +0300, Kostiantyn Sokolinskyi wrote:
> > Hallo!
> >
> > On Monday the code was committed and tonight I committed it again.
>
> It's nice to see so much activity going on.
>
> > DaisyPublisherHtmlPart class developed to support inlined tags
> > conversion using DOM API. All the classes that take part in the
> > conversion mechanism are updated to work over DaisyPublisherHtmlPart.
> >
> > IDaisyPublisherResponseTemplate revised to afford better flexibility.
> > Smarty and XSLT implementations of the interface are included.
> >
> > Query styling is supported in
> > SmartyDaisyPublisherInlinedTagsConvertor. You could look through
> > convertSearchResults() method. It uses "styleHint" attribute to select
> > appropriate template supplied by the user.
>
> nice!
>
> >
> > DaisyPublisherResponsePreparedDocuments applies a template on
> > <p:preparedDocument> tag. Support for different DocumentTypes in
> > included (templates for SimpleDocument (preparedDoc.tpl) and Image
> > (preparedDocImage.tpl) are provided in templates dir). The class fully
> > supports document inclusion. The template for the whole <p:document>
> > is applied after processing all the <preparedDocument>s and
> > inclusions. Inclusions are made using string functions. As all the
> > HTML processed using DOM API inclusion can be done using DOM - all the
> > code supplied by the user's templates must be XML compatible.
> >
> > The problem I encountered tonight is that &nbsp; entity cannot be used
> > in the templates as DOMDocument::loadXML()  method raises an error
> > "Entity 'nbsp' not defined in Entity". So as far as I understand I
> > should add appropriate DTD to the document to avoid such errors. Do
> > you think I can use XHTML DTD for that?
>
> No, I wouldn't do that. For the "&nbsp;" issue, simply solve that by
> replacing it by "&#160;".
>
> Personally I don't like DTD's very much, for a variety of reasons, but
> DTDs for something like XHTML always seemed rather absurd to me, since
> XHTML uses namespaces and DTDs don't support namespaces. Also, loading
> DTDs takes times and will slow down the XML parsing. So, I simply
> wouldn't put time into this and use "&#160;" (most people familiar with
> XML/XSL know this one by heart).
Ok. I will not do any conversion and will leave it for
template-writers. I think in the documentation it should be just
noticed for the framework users.
>
> >
> > This week I eventually will add better errors handling to the
> > framework and work on other publisher requests.
>
> ok.
>
> >
> > Waiting for your comments on the code committed.
>
> I'll (try to) try it out in the weekend.
>
> I've had a look around at the code, the DOM-usage is definitely better
> from an XML-point-of-view than the earlier regexp stuff.
>
> It's still not quite optimal that a lot of conversion between different
> data structures is going on (DOM, SimpleXML, XML-as-text). However,
> unless you have a unified model for representing the XML (something that
> combines the ease-of-use and template-friendliness of SimpleXML and the
> XML-fidelity of DOM) there is probably little to do about it (now it's a
> bit late to start doing something about this).
>
The conversion from DOM to SimpleXML is unpainful as both use the same
data structure and inner library (libxml) and SimpleXML hash a
function to import data from DOM. Unfortunately DOM extension has no
such a possibility and data has to be converted to XML-as-text first.

> Another thing I've noticed is there are some hardcoded
> "http://localhost/" references in the smarty templates and some other
> locations.
In PHPDaisyPublisherInlinedTagsConvertor and
SmartyDaisyPublisherInlinedTagsConvertor classes that inherit
ADaisyPublisherInlinedTagsConvertor abstract class the
"http://localhost/" is hard-coded as they (descendant classes) are
made specifically for my test script. All the abstract functions
should be implemented by the user of the framework as I cannot imagine
what url requests (and template engines) he would use . I don't think
that any unified url reference method should be developed right now.
It's also up to the template writer (end-user) how to write the urls
in the templates, though PHP functions (methods) can be registered in
the Smarty template engine so the template writer could call them to
get actual url using daisy links I simply did not bothered about that
in the example templates. (php functions calls can also be done from
XSLT templates processed by PHP)
>
> Looking at SmartyDaisyPublisherResponseTemplate.php I see you
> instantiate "new SmartyPublisherResponseTemplate" but I don't find that
> class defined anywhere. Forgot to commit something, or I'm looking
> besides it?
I've committed the fixed file already. It was left after
SmartyPublisherResponseTemplate was renamed to
SmartyDaisyPublisherResponseTemplate and I didn't use the static
method after that so didn't noticed the bug.
>
> Regards,
>
> Bruno.
>
> --
> Bruno Dumon                             http://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> bruno at outerthought.org                          bruno at apache.org
>
> _______________________________________________
> daisy community mailing list
> Professional Daisy support: http://outerthought.org/site/services/daisy/daisysupport.html
> mail to: daisy at lists.cocoondev.org
> list information: http://lists.cocoondev.org/mailman/listinfo/daisy
>

-- 
Looking forward to hear from you,

Sinc. Yours
Kostiantyn Sokolinskyi