Hmmm. Looks like I'll have to learn more about this WADL. I was
approaching it from the XSLT side. Should've thought about the web
service side.
Thanks!
(Being a one man shop and very busy, I often end up reinventing the
wheel. It's a drag. I should get out more.)
Chas.
Tim Perrett wrote:
> Chas,
>
> What your talking about is object serilization - the helpers we both
> currently have, and the ones I plan to rebuild do not care about the
> output XML - it's more abstract than that (collections of implicit
> conversions etc)
>
> IMO - what your talking about is object serilization. There are a
> bunch of frameworks out which do this very effectivly (for better or
> worse, soap is an example of this), and personally, I'm not a fan of
> it: for me, REST services should be a lightweight DSL -if you then
> want automated tooling, just use WADL.
>
> Cheers, Tim
>
> Sent from my iPhone
>
> On 1 Feb 2009, at 05:47, "Charles F. Munat" <c...@munat.com> wrote:
>
>> Tim,
>>
>> I don't know much about the XMLApiHelper, but if you're headed down
>> this
>> route, there is an alternative syntax that you might want to consider.
>>
>> One of the things I might want to do with XML output from a REST
>> server,
>> for example, is create an interface to it using HTML. The easiest way
>> would be by using XSLT (or Scala) to convert the XML to XHTML, e.g. to
>> convert a collection of Users into a table.
>>
>> If each object/class has it's own element name, that makes things
>> difficult. In that instance, I would program my REST server to output
>> users thus:
>>
>> <collection className="User">
>> <object className="User">
>> <attribute name="id" format="integer">666</attribute>
>> <attribute name="nameFirst" format="name">Lou</attribute>
>> <attribute name="nameLast" format="surname">Cypher</attribute>
>> <collection className="PhoneNumber">
>> <object className="PhoneNumber">
>> <attribute name="region">US</attribute>
>> <attribute name="phoneType">mobile</attribute>
>> <attribute name="areaCode" format="areaCode">666</attribute>
>> <attribute name="exchange" format="exchange">666</attribute>
>> <attribute name="number" format="phone">6666</attribute>
>> <attribute name="extension" format="ext">6666</attribute>
>> </object>
>> <object className="PhoneNumber"/>
>> </collection>
>> </object>
>> <object className="User"/>
>> <object className="User"/>
>> </collection>
>>
>> This allows me to write one script that converts all collections to
>> tables, or alternatively to nested lists. It's more verbose (though
>> some
>> duplication could be eliminated), but it provides me with the
>> information I need to do the conversion and format the results.
>>
>> Just a thought...
>>
>> Chas.
>>
>> Tim Perrett wrote:
>>> Guys,
>>>
>>> Just doing some work with the XMLApiHelper and im finding some things
>>> that can be improved. For instance, the trait provides createTag
>>> which
>>> you then have to override like so:
>>>
>>> def createTag(in: NodeSeq) = <api>{in}</api>
>>>
>>> IMO, it seems that this isnt ideal as if you were returning a list of
>>> users, your xml would be:
>>>
>>> <api>
>>> <user>....</user>
>>> <user>....</user>
>>> </api>
>>>
>>> It would be better to have a configurable root node, so its a more
>>> logical semantic:
>>>
>>> <users>
>>> <user>....</user>
>>> <user>....</user>
>>> </users>
>>>
>>> I've been playing around with the best way to do it and by changing
>>> the implicits and the xml build methods I now have it so that you can
>>> do:
>>>
>>> def listAllUsers = {
>>> ...
>>> ("users", listOfUsers)
>>> }
>>>
>>> This appears to be the best way to do it, otherwise things start
>>> getting messy?
>>>
>>> Whilst I can make these changes code wise, im very aware that ESME
>>> uses this helper a lot and this would mean some significant breaking
>>> changes in the api construction, both for ESME, and no doubt other
>>> projects. IMHO, the change is worth the hassle as it will make
>>> services up of more logically formed xml.
>>>
>>> What are people's thoughts?
>>>
>>> Cheers
>>>
>>> Tim
>
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---
