You are viewing a plain text version of this content. The canonical link for it is here.
Posted to photark-dev@incubator.apache.org by Henry Saputra <he...@gmail.com> on 2010/05/16 03:09:27 UTC
[PhotArk UI] Discussion for PhotArk UI framework direction
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.
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.
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.
Looking forward to hear from all of you.
Thanks,
- Henry
Re: [PhotArk UI] Discussion for PhotArk UI framework direction
Posted by Luciano Resende <lu...@gmail.com>.
On Sun, May 16, 2010 at 12:15 PM, Henry Saputra <he...@gmail.com> wrote:
> Hi All,
>
> For rendering part, I think that if we want the webapp and google-app to be
> more than simple sample to show how to get the backend/services end points,
> we need to add UI framework to simplify extension and adding more features
> such as GSOC projects for search/tag, and OpenID.
> These modules (ie webapp and google-app) will use other endpoints to
> actually get the data or server side logic that allow developers to build
> his/her own UI on top of PhotArk superb services.
>
> Even JSP is considered as server side technology what its actually do is to
> convert/compile the JSP file into servlet that handle the rendering in
> server side.
I see two issues with server side rendering :
- Scalability, as usually you have to go to server for generating
another piece of the ui... (e.g instead of requesting a new image and
updating the ui to change the image being displayed, you need to
submit and get a new ui rendered on the server)
- Loose flexibility, as if I understand what you are proposing,
data will be mashed together with the ui pieces during server
rendering
> When I said about server side rendering, I was proposing something like
> Apache Click that allows lightweight server side logic to allow easy
> templating for the html pages.
I'm not all familiar with Apache Click, but it seems that one issue
with that is that it brings lots of different JS frameworks to the UI,
and that might be an issue... but I don't want to jump to conclusions
as I haven't had a chance to deeply investigate the project.
> The idea is to allow serving dynamic html instead of creating individual
> html pages. It will go to become unmanageable pretty quick.
> Updates to the page from calling back to PhotArk services could happen in
> client side. The initial rendering and flow could be done in server side.
>
> As Martin and others have mentioned we shouldnt cluttered server side logic
> with UI logic.
> These rendering mechanism should live in its own maven module, such as
> photark-ui module, so it wont interfere with middle and back logic.
>
> Getting back to separation of concerns, based on some prev ideas what about
> splitting photark as these modules:
>
> UI
> -----
> This module should contain two major functionalities:
> -) rendering -> This should be photark UI framework for webapp and
> google-app. This part should generate dynamic html markups that could allow
> easy customization and extension as well as example on how to build client
> application to use photark.
> -) client side script/code -> This part contains javascript widgets and
> javascript code to send and process requests to/from photark services. This
> part should not depend on other client side framework.
>
> UI Services
> ------------------
> These are SCA components that handle requests from client.
> These could be components that Luciano proposed before:
> Content Repository and GalleryAPI
>
> Data Access Layers and Core Services
> ------------------------------------------------------------
> Provide abstraction for actual data for Gallery and Album. It could be File
> system, jcr, sdo, or other sources.
> This module also contain some bootstrap logic to select which composite file
> to launch (maybe as ContextListener)
>
> Based on the separation of concerns above PhotArk will expose these
> endpoints to users/developers:
> 1. Web application that fully render the UI to show full stack of PhotArk
> capabilities/features
> 2. client side library for manipulating contents and send request back to
> photark services.
> 3. Atom, REST and JSON-RPC endpoints to allow external developers to hit the
> server side functionalities directly.
>
> Thoughts?
>
Well, I guess lots of us have provided different point of views here,
but I don't want to discourage you so I was wondering if this is going
to be a totally separate module that won't cause any disruption to
current trunk, otherwise, if others members of the project are ok, I
could setup a branch/sandbox for you to play with this.
Thoughts ?
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: [PhotArk UI] Discussion for PhotArk UI framework direction
Posted by Henry Saputra <he...@gmail.com>.
Hi All,
For rendering part, I think that if we want the webapp and google-app to be
more than simple sample to show how to get the backend/services end points,
we need to add UI framework to simplify extension and adding more features
such as GSOC projects for search/tag, and OpenID.
These modules (ie webapp and google-app) will use other endpoints to
actually get the data or server side logic that allow developers to build
his/her own UI on top of PhotArk superb services.
Even JSP is considered as server side technology what its actually do is to
convert/compile the JSP file into servlet that handle the rendering in
server side.
When I said about server side rendering, I was proposing something like
Apache Click that allows lightweight server side logic to allow easy
templating for the html pages.
The idea is to allow serving dynamic html instead of creating individual
html pages. It will go to become unmanageable pretty quick.
Updates to the page from calling back to PhotArk services could happen in
client side. The initial rendering and flow could be done in server side.
As Martin and others have mentioned we shouldnt cluttered server side logic
with UI logic.
These rendering mechanism should live in its own maven module, such as
photark-ui module, so it wont interfere with middle and back logic.
Getting back to separation of concerns, based on some prev ideas what about
splitting photark as these modules:
UI
-----
This module should contain two major functionalities:
-) rendering -> This should be photark UI framework for webapp and
google-app. This part should generate dynamic html markups that could allow
easy customization and extension as well as example on how to build client
application to use photark.
-) client side script/code -> This part contains javascript widgets and
javascript code to send and process requests to/from photark services. This
part should not depend on other client side framework.
UI Services
------------------
These are SCA components that handle requests from client.
These could be components that Luciano proposed before:
Content Repository and GalleryAPI
Data Access Layers and Core Services
------------------------------------------------------------
Provide abstraction for actual data for Gallery and Album. It could be File
system, jcr, sdo, or other sources.
This module also contain some bootstrap logic to select which composite file
to launch (maybe as ContextListener)
Based on the separation of concerns above PhotArk will expose these
endpoints to users/developers:
1. Web application that fully render the UI to show full stack of PhotArk
capabilities/features
2. client side library for manipulating contents and send request back to
photark services.
3. Atom, REST and JSON-RPC endpoints to allow external developers to hit the
server side functionalities directly.
Thoughts?
- Henry
On Sun, May 16, 2010 at 8:51 AM, Martin Cooper <ma...@apache.org> wrote:
> On Sat, May 15, 2010 at 9:54 PM, Luciano Resende <lu...@gmail.com>
> wrote:
> > Let me start for apologizing for the long e-mail :)
> >
> > On Sat, May 15, 2010 at 8:09 PM, Henry Saputra <he...@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.
> >
> >> 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,
>
> IMO, this is by far the most important piece, and it's crucial that we
> get this right. Once we have the right service interface (and yes, I
> prefer RESTful too), anyone can easily build an app on top of it,
> regardless of technology. I should be able to build a DHTML app, as
> our sample demonstrates, or use Flex or AIR or Silverlight or JavaFX
> or whatever. I could perhaps even build a scripted app that doesn't
> have or need a UI itself. But we have to keep these options in mind as
> we design the service interface, and not "accidentally" nail it to
> DHTML.
>
> > --------- 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)
>
> I'm not convinced about this, although I'm open to being persuaded. On
> the plus side, it might help people build apps faster, but on the
> minus side, its very existence means that we probably don't have the
> optimal service interface. That suggests to me that we should focus on
> getting the service interface right, instead of compensating for it
> with another layer in the client.
>
> Also, if we do have such a layer, I believe it is important that it
> _not_ rely on any other JavaScript framework. Doing that will
> prejudice the experience towards whatever framework we choose, rather
> than let the consumer choose their own. That is, if we choose to build
> such a layer on top of Dojo, for instance, and I want to build my app
> using ExtJS, now I have to choose between having 2 different
> JavaScript frameworks in my app (bad) or having to re-implement the UI
> API using something else (bad).
>
> A JavaScript UI API is also not useful for anyone using other
> technologies such as Flex.
>
> > 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.
>
> I definitely agree with this being independent of the server side.
>
> > 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.
>
> I am with you on server-side rendering. In addition to the reasons you
> mention, which I agree with, it also introduces another technology
> boundary for someone who wants to customise the app; now they may need
> to deal with Java and / or Java configuration in addition to DHTML or
> their chosen client-side technology.
>
> --
> Martin Cooper
>
>
> > Thoughts ? What do others think about this ?
> >
> > --
> > Luciano Resende
> > http://people.apache.org/~lresende
> > http://twitter.com/lresende1975
> > http://lresende.blogspot.com/
> >
>
Re: [PhotArk UI] Discussion for PhotArk UI framework direction
Posted by Martin Cooper <ma...@apache.org>.
On Sat, May 15, 2010 at 9:54 PM, Luciano Resende <lu...@gmail.com> wrote:
> Let me start for apologizing for the long e-mail :)
>
> On Sat, May 15, 2010 at 8:09 PM, Henry Saputra <he...@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.
>
>> 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,
IMO, this is by far the most important piece, and it's crucial that we
get this right. Once we have the right service interface (and yes, I
prefer RESTful too), anyone can easily build an app on top of it,
regardless of technology. I should be able to build a DHTML app, as
our sample demonstrates, or use Flex or AIR or Silverlight or JavaFX
or whatever. I could perhaps even build a scripted app that doesn't
have or need a UI itself. But we have to keep these options in mind as
we design the service interface, and not "accidentally" nail it to
DHTML.
> --------- 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)
I'm not convinced about this, although I'm open to being persuaded. On
the plus side, it might help people build apps faster, but on the
minus side, its very existence means that we probably don't have the
optimal service interface. That suggests to me that we should focus on
getting the service interface right, instead of compensating for it
with another layer in the client.
Also, if we do have such a layer, I believe it is important that it
_not_ rely on any other JavaScript framework. Doing that will
prejudice the experience towards whatever framework we choose, rather
than let the consumer choose their own. That is, if we choose to build
such a layer on top of Dojo, for instance, and I want to build my app
using ExtJS, now I have to choose between having 2 different
JavaScript frameworks in my app (bad) or having to re-implement the UI
API using something else (bad).
A JavaScript UI API is also not useful for anyone using other
technologies such as Flex.
> 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.
I definitely agree with this being independent of the server side.
> 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.
I am with you on server-side rendering. In addition to the reasons you
mention, which I agree with, it also introduces another technology
boundary for someone who wants to customise the app; now they may need
to deal with Java and / or Java configuration in addition to DHTML or
their chosen client-side technology.
--
Martin Cooper
> Thoughts ? What do others think about this ?
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
>
Re: [PhotArk UI] Discussion for PhotArk UI framework direction
Posted by Suhothayan Sriskandarajah <su...@gmail.com>.
On 16 May 2010 18:57, Avdhesh Yadav <av...@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/
> > >
> >
>
Re: [PhotArk UI] Discussion for PhotArk UI framework direction
Posted by Avdhesh Yadav <av...@avdheshyadav.com>.
+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 <he...@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 <he...@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/
> >
>
Re: [PhotArk UI] Discussion for PhotArk UI framework direction
Posted by Henry Saputra <he...@gmail.com>.
Hi Luciano,
Long emails always welcomed =)
My comments inline:
On Sat, May 15, 2010 at 9:54 PM, Luciano Resende <lu...@gmail.com>wrote:
> Let me start for apologizing for the long e-mail :)
>
> On Sat, May 15, 2010 at 8:09 PM, Henry Saputra <he...@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://twitter.com/lresende1975
> http://lresende.blogspot.com/
>
Re: [PhotArk UI] Discussion for PhotArk UI framework direction
Posted by Luciano Resende <lu...@gmail.com>.
Let me start for apologizing for the long e-mail :)
On Sat, May 15, 2010 at 8:09 PM, Henry Saputra <he...@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.
> 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,
--------- 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 ?
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/