incubator-photark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Avdhesh Yadav <...@avdheshyadav.com>
Subject Re: [PhotArk UI] Discussion for PhotArk UI framework direction
Date Sun, 16 May 2010 13:27:28 GMT
+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 <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://twitter.com/lresende1975
> > http://lresende.blogspot.com/
> >
>

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