I meant to ask. Of the options to improve the API, which would people prefer, or are there any other suggestions?
My current preference is for the building up of the SDO Atom model programmatically because this will not require the developer to specify they want to use something other than SDO. I think the PHP class approach might need a new annotation to say they want classes (POPO - Plain Old PHP Objects) rather than SDO. On 30 Aug, 09:29, Graham Charters <[EMAIL PROTECTED]> wrote: > The many-valued nature of a lot of the properties is unfortunately due > to the inability of XML schema to accurately describe the Atom > Syndication Format. It's a while since I wrote the schema, but I seem > to recall it was to do with the use of <choice maxOccurs="unbounded" />. The > Atom XML is defined in terms of Relax NG which does a far > > better job. On the plus side, the SDO model could do quite a good job > of representing Atom, so one thought I had was to programmatically > build up an SDO Atom model in the binding. Applications could work > with this cleaner version and then in the binding we would use the XML > schema-based version to handle the serialization/deserialization. > Another thought was to define PHP classes to represent the Atom format > and again use the XML schema-based SDO to do the serialization/ > deserialization. > > I quite like the heredoc approach as an alternative, which is why I > write the sample code to do that :-D > > For the XML serialization using the default namespace, would we want > this to be determined from the XML schema? So for example, our > Atom1.0.xsd has the default namespace being that of Atom, so the > instance documents could do the same. > > Graham. > > On 23 Aug, 20:45, Caroline Maynard <[EMAIL PROTECTED]> wrote: > > > Matthew Peters wrote: > > > Thank you. The mistake I was making was putting > > > $entry_author->name = $author; > > > when I should have had > > > $entry_author->name[] = $author; > > > > Isn't it all horrid. When you try to write it from scratch, and if you > > > do not know what you are doing (that was me) it's baffling. > > > It is quite horrid, but there is a way you can examine the structures - > > if you create an SDO_Model_ReflectionDataObject from the sdo > > representing the atom entry, it will show you the details. For example, > > the author property is described as: > > http://www.w3.org/2005/Atom#personConstruct$author[] { > > commonj.sdo#String $name[]; > > commonj.sdo#String $uri[]; > > http://www.w3.org/2005/Atom#emailType$email[]; > > http://www.w3.org/2005/Atom#extensionType$extension[] { > > } > > } > > which was how I knew that $author->name must be many-valued. > > > > The code I > > > had (i.e. without the []) executes, but nothing comes out in the > > > generated xml, or var_dump, so where the author value goes in that > > > case I don't know. > > > Hmm, neither do I. Sounds like an sdo bug. > > > > And as far as I know there is not an example of it in the examples. > > > The only places I could see where content was being built up, the code > > > was using heredocs instead. It looks like our examples need a > > > considerable overhaul (I am remembering your point 1. above also.) > > > Agreed, I only found examples that sent pre-canned xml from heredocs, > > which seems to miss one of the benefits of using SCA. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~----------~----~----~----~------~----~------~--~---
