+1 for UI API. For templating we can investigate DTL(*Django Temlpating Language*) which is a templating language for Dojo . I think we should not pollute the server-side with the rendering logic.As Luciano mentioned we can have services API(e.g Gallery API) which provide the content.Any client can access the content through the services API.
-- Avdhesh Yadav http://www.avdheshyadav.com http://twitter.com/yadavavdhesh On Sun, May 16, 2010 at 12:09 PM, Henry Saputra <[email protected]>wrote: > Hi Luciano, > > Long emails always welcomed =) > > My comments inline: > > On Sat, May 15, 2010 at 9:54 PM, Luciano Resende <[email protected] > >wrote: > > > Let me start for apologizing for the long e-mail :) > > > > On Sat, May 15, 2010 at 8:09 PM, Henry Saputra <[email protected]> > > wrote: > > > Hi All, > > > > > > Currently PhotArk web application (webapp) and google-app modules use > > just > > > html files for UI and relying on Javascript for sending request back to > > > PhotArk components and updating the markup on json callback. > > > This design is hard to maintain and extend to add more features > > > and customization. > > > > > What are the main issues you are having here ? Can you describe your > > pain points ? I do believe our current design has grown in the wrong > > direction, and instead of providing a facade service that return > > business objects to the client, we have created multiple operations to > > return specific information. I want to start fixing that using > > PHOTARK-42. > > > > > Not so much about pain points =) > I just thought what would be the purpose of the photark web app and the > google-app modules? > > Will they be just samples on how write web client to call photark SCA end > points or they will be more like base modules that developers could > extend/modify to suit their look and feel requirements. > > > If its ok with everyone I would like to start discussion about direction > > to > > > improve the UI design/framework to allow customization and easy > > development > > > to add more features. > > > > > > > +1, we definitely need a easy way to allow users that are using the > > sample UI we provide and customize it, but see below for some thoughts > > on design direction. > > > > > Here are some ideas to get the discussion rolling: > > > > > > 1. Add PhotArkRenderingServlet component to generate the markup for > both > > > webapp and google-app. The servlet will have PhotArkHtmlRenderer class > to > > > render html markups but not limited to it. > > > External developers could replace this renderer with his own or extend > > > the PhotArkHtmlRenderer to override some methods for custom behaviors. > > > The advantage with this approach is that we control the rendering > process > > > which allows us to customize for PhotArk efficiency and performance. > > > The downside is we control the rendering process (^_^) so we have to > add > > > some foundation code to make it work. > > > > > > 2. Use existing lightweight web framework that supports templating like > > > Apache Click (http://click.apache.org/). This will allow reuse of html > > pages > > > for easy maintenance. > > > The advantage with this approach is that we have most boilerplate codes > > > being taking care of by the web framework. Just need to our own custom > > code > > > for PhotArk UI. > > > The downside is we add dependency on another project and add learning > > curve > > > to developers when trying to adopt PhotArk. > > > > > > > > > I believe that the most flexible way is to apply separation of > > concerns and have different layes for the project : > > > > Content Repository - an abstraction layer to interact with the photo > > storage, we are currently focusing on JCR as the main repository, but > > I believe we can have that to be easily replaced with simple > > FileSystem or something for Google AppEngine. > > > > Gallery API - A layer that will allow client applications to interact > > with the content repository. The client can be web browser or other > > different remote client that has a need to integrate with the photo > > content repository. As for this layer, we should fixup the current > > implementation and make the client/server conversation more atomic > > passing business objects instead of using a call to retrieve specific > > information. In the future, we can think about a more pure REST > > approach for this API, and I'm finalizing a REST binding in Tuscany > > that would help us accomplish this second phase, > > > > > I think this is what you were after with PHOTARK-42 jira? > > +1 using the REST API for this. > > --------- Separation layer from server > > > > UI API - This is something I've been thinking, but I don't have > > nothing concrete on it yet. The idea was to provide a JS Client API > > that would allow to simplify the creation of different UI (web pages) > > > > UI - This is the presentation layer, and I believe it should be > > independent of the server side to allow other websites and different > > clients to easily integrate with the project. Customization of the > > sample ui we provide should be done on this layer, and I was thinking > > if we could use something similar to what blogger use and allow some > > type of templating that would be handled on the JS side. Looks like > > there is already some support for this in dojo. > > > > If we move to have UI rendering on the server side, I think we will > > loose a lot of flexibility, and will most likely add some complexity > > for UI Developers trying to just consume some of PhotArk content to > > integrate in their website/mashup. > > > > Thoughts ? What do others think about this ? > > > > Separation of layers are always good =) > > +1 to have UI API, maybe we could add Javascript library to wrap dojo > calls? > > I think by moving the rendering task to the server (via servlet or web > framework) add flexibility for external developers if we want to make the > webapp and google app modules as "production" ready. Meaning that > developers > could extend or replace our default look and feel by extending or replacing > template files and styles to achieve the desired UI. > > For UI Developers that simply want to consume PhotArk content we could ask > them to use the UI API to get the data. > > Just my 2 cents. > > - Henry > > > > > > -- > > Luciano Resende > > http://people.apache.org/~lresende<http://people.apache.org/%7Elresende> > > http://twitter.com/lresende1975 > > http://lresende.blogspot.com/ > > >
