[daisy] PHP framework two weeks report

[Bruno Dumon]

Hi,

On Fri, 2006-08-04 at 11:48 +0300, Kostiantyn Sokolinskyi wrote:
> Hallo!
> 
> 2006/8/2, Bruno Dumon <bruno at outerthought.org>:
> > Hi Kostiantyn,
> >
> > On Wed, 2006-08-02 at 13:39 +0300, Kostiantyn Sokolinskyi wrote:
> > > Hallo!
> > >
> > > This is the report for the last two weeks of development (actually
> > > only one whole week due to some troubles).
> >
> > No problem, but I hope next reports will be weekly instead of biweekly.
> >
> > >
> > > - the problem with inlined tags changing is solved using string
> > > functions - that's the only convinient way I found. It's also made in
> > > the way that any future inlined tags conversion could be handled in an
> > > easy way. Search results' styling could be held in the actual abstract
> > > class descendant as the functions recieve XML node of the tag
> > > converted.
> >
> > You processed some inline tags using string functions: I'm not much
> > impressed :-(
> > Oh well, I assume it's the PHP way of processing XML? :-)
> It was the only way I found after a several days of trying different
> approaches.

If you spend *days* looking for different approaches, it would have been
nice if you sent a summary to the list of the approaches you tried so
that we could follow the reasoning that led to using this approach.

>  The problem is that SimpleXMLExtension (which I generally
> use for xml processing) cannot change one tag in the XML tree on
> another. So if i want change <searchResult> on <table> it becomes
> immposible and I want to preserve SimpleXML structure.

Maybe that's enough reason to decide not to use SimpleXML, or at least
not for the HTML parts. There are generally lots of different XML APIs,
some more suited towards "data" oriented XML, and others towards
"document" oriented XML (with document oriented, I mean XML containing
mixed content, as is the case for HTML). ("mixed content" is the XML
term form when text and tags can occur as siblings)

For the publisher responses, a combined approach would in fact be very
useful: everything except for the HTML parts can be nicely represented
with something like SimpleXML, and the HTML parts could be handled with
something else (DOM would be an acceptable solution).

> > What inline tags are we talking about here? <a> and <img> were already
> > handled as written in your previous report, and here you write
> > searchResult styling 'could' be done using the same thing. What else is
> > left?
> <a> and <img> were handled just using SimpleXML but then I realized
> that the way they were handled is not appropriate for <searchResult>
> tag. So processing of all the tags was made in the new way. Also any
> new tag that could appear in Daisy later can be easily handled in the
> same way.

okay

> >
> > BTW, something like styling search results shouldn't require
> > subclassing, the framework should provide some mechanism to use n
> > templates for this (but maybe that's actually there, with the
> > DaisyPublisherResponseTemplateProcessor class?).
> >
> What we decided earlier is using an interface for inlined tags
> conversion. But later on I realized that I need not just interface but
> an abstarct class which will do all the job for tags convesion. The
> user can use either php or an other template engine in that class.
> It's up to him. The mechanism for using any template engines
> (interface) was developed yet a month ago ;)

I think I get it.

When you commit this stuff, please include an example of how one would
actually do this (style search results using a template).

> > >
> > > - the previous method is also used for documents inclusion in the
> > > DaisyPublisherResponsePreparedDocuments class that recieves publisher
> > > response with already converted inlined tags and applies supplied
> > > templates.
> >
> > So the embedding of included documents into the main document is already
> > working?
> Yes. I just check now some minor bugs.

cool.

> >
> > >  It seems to me that two templates should be used: one for
> > > each <d:document> tag and one for the <p:preparedDocuments> in order
> > > to to compose the whole document.
> >
> > Indeed, that's a good approach. The Daisy Wiki does it in the same way.
> >
> > >  It seems to that it could be used
> > > for adding coments, menus and other information needed to be processed
> > > for the actually requested document and not for the included ones.
> > >
> > > - to the DaisyPublisherResponseTemplateProcessor class (intended for
> > > applying templates on any tags supplied) the possibility of returning
> > > any attributes' values from the parent xml node within the html code
> > > is added. I think I could also add possibility to get any child nodes
> > > attributes values using xpath espressions supplied.
> >
> > I'm missing the context to know for what this is useful. An example of
> > such a template would help.
> Now I'am using parent node attribute retrieval for assembling included
> documents. I apply templates on all the <preparedDocument>s in the
> <preparedDocuments> and also get "id" attribute by which I assemble
> them later.
> Getting any child nodes attributes will not be usefull I think now.
> >
> > >
> > > This week I am planning to add some minor enhancments in some of the
> > > publisher processing classes. Error handling will be also considered
> > > this week.
> >
> > I'm wondering when you'll commit some code again? Last commit was from
> > July 4 (!). Don't hesitate to regurarly commit the progress you've made,
> > even if it's not 'perfect' yet. If you could commit something before the
> > weekend, I should be able to try it out then.
> I will try but I think I will manage to do that by Monday.

ok, looking forward to that.

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno at outerthought.org                          bruno at apache.org