[daisy] PHP framework two weeks report

[Kostiantyn Sokolinskyi]

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. 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.

>
> 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.
>
> 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 ;)
> >
> > - 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.
>
> >  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.
>
> --
> 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