[Lift] Re: Suggested breaking changes for XMLApiHelper
> Hmmm. Looks like I'll have to learn more about this WADL. Both WADL and WSDL2 can describe REST services. The latter is some time away, and WADL, whilst young, is here right now: https://wadl.dev.java.net/ > I was > approaching it from the XSLT side. Should've thought about the web > service side. Sure - to a certain degree I still think if you want object serialization, using a standardized framework is better... But now im rambling ;-) If you have any questions about doing REST in lift, just post up and I'll do my best to answer :-) 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 -~--~~~~--~~--~--~---
[Lift] Re: Suggested breaking changes for XMLApiHelper
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" 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:
>>
>>
>>
>> 666
>> Lou
>> Cypher
>>
>>
>>US
>> mobile
>> 666
>> 666
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 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) = {in}
>>>
>>> IMO, it seems that this isnt ideal as if you were returning a list of
>>> users, your xml would be:
>>>
>>>
>>>
>>>
>>>
>>>
>>> It would be better to have a configurable root node, so its a more
>>> logical semantic:
>>>
>>>
>>>
>>>
>>>
>>>
>>> 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
-~--~~~~--~~--~--~---
[Lift] Re: Suggested breaking changes for XMLApiHelper
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" 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:
>
>
>
> 666
> Lou
> Cypher
>
>
>US
> mobile
> 666
> 666
>
>
>
>
>
>
>
>
>
>
> 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) = {in}
>>
>> IMO, it seems that this isnt ideal as if you were returning a list of
>> users, your xml would be:
>>
>>
>>
>>
>>
>>
>> It would be better to have a configurable root node, so its a more
>> logical semantic:
>>
>>
>>
>>
>>
>>
>> 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
-~--~~~~--~~--~--~---
[Lift] Re: Suggested breaking changes for XMLApiHelper
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:
666
Lou
Cypher
US
mobile
666
666
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) = {in}
>
> IMO, it seems that this isnt ideal as if you were returning a list of
> users, your xml would be:
>
>
>
>
>
>
> It would be better to have a configurable root node, so its a more
> logical semantic:
>
>
>
>
>
>
> 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
-~--~~~~--~~--~--~---
[Lift] Re: Suggested breaking changes for XMLApiHelper
Mmmm - I see value in HTTP responses being in one file, and as far as im aware that's the case now? IMO, the file was massively cluttered before with CSS responses, JS responses (of which there are a lot) etc etc etc. Having them a little segregated makes the code easier to maintain. What are your thoughts? Cheers Tim > Excellent. > > Next time you're in the Response code, can you put all the responses in a > single file? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: Suggested breaking changes for XMLApiHelper
On Sat, Jan 31, 2009 at 7:53 AM, Tim Perrett wrote:
>
>
> Hey David,
>
> Ok splendid - another alternative it is.
>
> FYI - I added a few more HTTP code representations to HttpResponse.scala
> last night... Nothing crazy, but just some other ones I needed. I also need
> to add some extra parameters to some of them so they directly represent the
> RFC spec, but they are OK for the moment :-)
Excellent.
Next time you're in the Response code, can you put all the responses in a
single file?
>
>
> Cheers
>
> Tim
>
> On 31/01/2009 15:48, "David Pollak" wrote:
>
> > Tim,
> >
> > Please don't change the existing XMLApiHelpers, but feel free to create
> an
> > alternative. I expect different people are going to have different
> styles and
> > providing them with lots of alternatives will be important.
> >
> > I'm planning another alternative that will returns failures as different
> HTTP
> > codes to make things more RESTful.
> >
> > Thanks,
> >
> > David
> >
> > On Sat, Jan 31, 2009 at 3:07 AM, 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) = {in}
> >>
> >> IMO, it seems that this isnt ideal as if you were returning a list of
> >> users, your xml would be:
> >>
> >>
> >>
> >>
> >>
> >>
> >> It would be better to have a configurable root node, so its a more
> >> logical semantic:
> >>
> >>
> >>
> >>
> >>
> >>
> >> 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
> >>
> >
> >
>
>
>
> >
>
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[Lift] Re: Suggested breaking changes for XMLApiHelper
Hey David,
Ok splendid - another alternative it is.
FYI - I added a few more HTTP code representations to HttpResponse.scala
last night... Nothing crazy, but just some other ones I needed. I also need
to add some extra parameters to some of them so they directly represent the
RFC spec, but they are OK for the moment :-)
Cheers
Tim
On 31/01/2009 15:48, "David Pollak" wrote:
> Tim,
>
> Please don't change the existing XMLApiHelpers, but feel free to create an
> alternative. I expect different people are going to have different styles and
> providing them with lots of alternatives will be important.
>
> I'm planning another alternative that will returns failures as different HTTP
> codes to make things more RESTful.
>
> Thanks,
>
> David
>
> On Sat, Jan 31, 2009 at 3:07 AM, 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) = {in}
>>
>> IMO, it seems that this isnt ideal as if you were returning a list of
>> users, your xml would be:
>>
>>
>>
>>
>>
>>
>> It would be better to have a configurable root node, so its a more
>> logical semantic:
>>
>>
>>
>>
>>
>>
>> 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
-~--~~~~--~~--~--~---
[Lift] Re: Suggested breaking changes for XMLApiHelper
Tim,
Please don't change the existing XMLApiHelpers, but feel free to create an
alternative. I expect different people are going to have different styles
and providing them with lots of alternatives will be important.
I'm planning another alternative that will returns failures as different
HTTP codes to make things more RESTful.
Thanks,
David
On Sat, Jan 31, 2009 at 3:07 AM, 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) = {in}
>
> IMO, it seems that this isnt ideal as if you were returning a list of
> users, your xml would be:
>
>
>
>
>
>
> It would be better to have a configurable root node, so its a more
> logical semantic:
>
>
>
>
>
>
> 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
> >
>
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
