incubator-photark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suhothayan Sriskandarajah <suhotha...@gmail.com>
Subject Re: [PhotArk UI] Discussion for PhotArk UI framework direction
Date Sun, 16 May 2010 15:14:28 GMT
On 16 May 2010 18:57, Avdhesh Yadav <avd@avdheshyadav.com> 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 <henry.saputra@gmail.com
> >wrote:
>
> > Hi Luciano,
> >
> > Long emails always welcomed =)
> >
> > My comments inline:
> >
> > On Sat, May 15, 2010 at 9:54 PM, Luciano Resende <luckbr1975@gmail.com
> > >wrote:
> >
> > > Let me start for apologizing for the long e-mail :)
> > >
> > > On Sat, May 15, 2010 at 8:09 PM, Henry Saputra <
> henry.saputra@gmail.com>
> > > 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/
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message