On 16 May 2010 18:57, Avdhesh Yadav <[email protected]> wrote: > +1 for UI API. > > For templating we can investigate DTL(*Django Temlpating Language*) which > is > a templating language for Dojo . >
+1 for the UI API and using Dojo for template > 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. > > I too think we should have a proper service API which is independent of rendering. So that there wont be any limitations or constraints in implementing the front end. Suho -- > 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://people.apache.org/%7Elresende> > > > http://twitter.com/lresende1975 > > > http://lresende.blogspot.com/ > > > > > >
