[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tapestry-dev
Subject:    Re: Tapestry to natively emit JSON?
From:       "Thiago H. de Paula Figueiredo" <thiagohp () gmail ! com>
Date:       2017-04-25 11:55:18
Message-ID: CAE_88GYe4aO5u+3Vbi3NkgpVrL8sPzhKBi6efUiO9kSnVY00QA () mail ! gmail ! com
[Download RAW message or body]


On Mon, Apr 24, 2017 at 4:00 AM, Qbyte Consulting <qbyteconsulting@gmail.com
> wrote:

> Hi,
>

Hi!


> Thanks for the feedback.
>
> Which tapestry class is responsible for parsing the templates and
> augmenting the page classes to perform rendering?
>

TemplateParserImpl does the parsing, but then it parses XML, so it's not
applicable to your scenario at all, as you need to parse a completely new
language. Bytecode manipulation is done in PlasticClass instances.

You remember you can return JSONObject and JSONArray in onActivate() and
event handler methods, do you? I'm sorry, I still believe this project is
too much effort for too little benefit (unless you want to do it for fun,
and fun is a great reason to do something).


>
> J
>
> On Wed, Apr 19, 2017 at 3:18 AM, Thiago H. de Paula Figueiredo <
> thiagohp@gmail.com> wrote:
>
> > Hi!
> >
> > I don't think adapting Tapestry's template engine to support templating
> > JSON is a good idea. It was built to output HTML and XML and nothing
> else.
> > Is there anything else that does what you want? Why not using a generic
> > template engine like FreeMarker or, better yet, use some Java JSON mapper
> > like Jackson? I do see the point of implementing some Java class to
> > Tapestry JSON object mapper, but as a template, I see none, I'm sorry. If
> > you want to implement it, go ahead. :)
> >
> > Regarding reflection, the Tapestry BeanModel classes, which are now in a
> > separate JAR and can be used without tapestry-core, are very fast and
> does
> > caching of everything got by reflection, so they're a solid foundation
> for
> > doing what you want.
> >
> > On the other hand, supporting PUT and DELETE HTTP methods in Tapestry
> pages
> > is something I had some thoughts over time.
> >
> >
> > On Tue, Apr 18, 2017 at 12:11 PM, Qbyte Consulting <
> > qbyteconsulting@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > Would it be feasible or indeed sensible(?) to convert/adapt Tapestry to
> > > render JSON?
> > >
> > > Page classes would provide API endpoints and unpack params and body
> > content
> > > to properties and the templates would have JSON instead of TML. I'd
> also
> > > want to modify the tapestry tags (t:if t:loop etc) to something much
> more
> > > simple and JSONesque.
> > >
> > > The page classes would support the GET/POST/PUT and so forth by
> > convention.
> > > I also envisage being able to filter, resort and augment responses
> > through
> > > an execution chain.
> > >
> > > i.e: a JSON template
> > >
> > > {
> > >     "id": $,
> > >     ?"name": $,
> > >     <prices id='$' orderBy='ASC'>,
> > >     "tags": [$]}
> > >
> > >
> > > $ would call corresponding getter methods e.g. getId, getTags etc..
> > > ? would invoke hasName and render the name value if true
> > > <> would embed components - <prices...> could render "prices" :
> [1,2,3],
> > >
> > > I'd like to harness Tapesty to emit JSON from rendering char streams
> > > instead of having to use concrete domain classes that have to be
> > reflected
> > > and such as per JAXB and other similar frameworks that seem to make a
> > meal
> > > of JSON. I'd like plastic to convert the template into stream emitter
> > > methods that are called transparently in the plastic classes. Hiding
> the
> > > boilerplate code
> > >
> > > I like the idea of writing the JSON template myself, it's clearer more
> > > flexible and can stream and follows the ethos of Tapestry. Reflection
> > must
> > > slow the rendering down a lot.
> > >
> > > Is this crazy, any thoughts? I want to have flexibility and write
> minimum
> > > code, and max reuse things Tapestry is good with.
> > >
> > > John
> > >
> >
> >
> >
> > --
> > Thiago
> >
>



-- 
Thiago


[prev in list] [next in list] [prev in thread] [next in thread]