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 "Luciano Resende (JIRA)" <ji...@apache.org> on 2010/05/15 08:15:43 UTC
[jira] Created: (PHOTARK-42) Improve PhotArk services refactoring
Services and Model Objects
Improve PhotArk services refactoring Services and Model Objects
---------------------------------------------------------------
Key: PHOTARK-42
URL: https://issues.apache.org/jira/browse/PHOTARK-42
Project: PhotArk
Issue Type: Improvement
Components: PhoatArk Services
Affects Versions: PhotArk M2
Reporter: Luciano Resende
Priority: Critical
Fix For: PhotArk M3
The current album service has grown out of control, and the client makes multiple calls to the service to retrieve multiple album information.
We should start using more model/business objects, and stateless services that act on top of these objects.
I'd like to propose we start defining Album as pure model/business objects that will have all album related info (e.g name, description, cover image url, etc) and same thing with Image.
As for services, we should create a facade service to retrieve info in a more atomic way, e.g Gallery.getAlbum(albumName) retrieve a album model object with all info for the album at once. We might have a second operation to retrieve list of album images if we think it's too heavy to retrieve all at once....
Once we have this, we can start looking into applying more RESt style APIs and revisit how we can start taking advantage of http caching to improve performance of the overall client/server experience.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (PHOTARK-42) Improve PhotArk services by
refactoring current Services and Model Objects
Posted by "Luciano Resende (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PHOTARK-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12877356#action_12877356 ]
Luciano Resende commented on PHOTARK-42:
----------------------------------------
Thanks John Pradeep, partial patch applied.
> Improve PhotArk services by refactoring current Services and Model Objects
> --------------------------------------------------------------------------
>
> Key: PHOTARK-42
> URL: https://issues.apache.org/jira/browse/PHOTARK-42
> Project: PhotArk
> Issue Type: Improvement
> Components: PhoatArk Services
> Affects Versions: PhotArk M2
> Reporter: Luciano Resende
> Priority: Critical
> Fix For: PhotArk M3
>
> Attachments: photark-jcr.patch
>
>
> The current album service has grown out of control, and the client makes multiple calls to the service to retrieve multiple album information.
> We should start using more model/business objects, and stateless services that act on top of these objects.
> I'd like to propose we start defining Album as pure model/business objects that will have all album related info (e.g name, description, cover image url, etc) and same thing with Image.
> As for services, we should create a facade service to retrieve info in a more atomic way, e.g Gallery.getAlbum(albumName) retrieve a album model object with all info for the album at once. We might have a second operation to retrieve list of album images if we think it's too heavy to retrieve all at once....
> Once we have this, we can start looking into applying more RESt style APIs and revisit how we can start taking advantage of http caching to improve performance of the overall client/server experience.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (PHOTARK-42) Improve PhotArk services by
refactoring current Services and Model Objects
Posted by "John Pradeep (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PHOTARK-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
John Pradeep updated PHOTARK-42:
--------------------------------
Attachment: photark-jcr.patch
Have refactored the JCR Gallery service to follow REST style, need your feedback/comment on the same.
I still have to write JUNIT test cases for the same and make sure it is complete, but before that i want to know if the appraoch taken is right.
Please provide your suggestion/comments to make sure i have not missed out anything.
Note: The patch should be applied for
https://svn.apache.org/repos/asf/incubator/photark/branches/photark-rest/photark-jcr
> Improve PhotArk services by refactoring current Services and Model Objects
> --------------------------------------------------------------------------
>
> Key: PHOTARK-42
> URL: https://issues.apache.org/jira/browse/PHOTARK-42
> Project: PhotArk
> Issue Type: Improvement
> Components: PhoatArk Services
> Affects Versions: PhotArk M2
> Reporter: Luciano Resende
> Priority: Critical
> Fix For: PhotArk M3
>
> Attachments: photark-jcr.patch
>
>
> The current album service has grown out of control, and the client makes multiple calls to the service to retrieve multiple album information.
> We should start using more model/business objects, and stateless services that act on top of these objects.
> I'd like to propose we start defining Album as pure model/business objects that will have all album related info (e.g name, description, cover image url, etc) and same thing with Image.
> As for services, we should create a facade service to retrieve info in a more atomic way, e.g Gallery.getAlbum(albumName) retrieve a album model object with all info for the album at once. We might have a second operation to retrieve list of album images if we think it's too heavy to retrieve all at once....
> Once we have this, we can start looking into applying more RESt style APIs and revisit how we can start taking advantage of http caching to improve performance of the overall client/server experience.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (PHOTARK-42) Improve PhotArk services by
refactoring current Services and Model Objects
Posted by "Henry Saputra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PHOTARK-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867844#action_12867844 ]
Henry Saputra commented on PHOTARK-42:
--------------------------------------
Instead of using TuscanyFilter we should create photark context listener to have Node launcher dynamically to choose between jcr composite or file system.
> Improve PhotArk services by refactoring current Services and Model Objects
> --------------------------------------------------------------------------
>
> Key: PHOTARK-42
> URL: https://issues.apache.org/jira/browse/PHOTARK-42
> Project: PhotArk
> Issue Type: Improvement
> Components: PhoatArk Services
> Affects Versions: PhotArk M2
> Reporter: Luciano Resende
> Priority: Critical
> Fix For: PhotArk M3
>
>
> The current album service has grown out of control, and the client makes multiple calls to the service to retrieve multiple album information.
> We should start using more model/business objects, and stateless services that act on top of these objects.
> I'd like to propose we start defining Album as pure model/business objects that will have all album related info (e.g name, description, cover image url, etc) and same thing with Image.
> As for services, we should create a facade service to retrieve info in a more atomic way, e.g Gallery.getAlbum(albumName) retrieve a album model object with all info for the album at once. We might have a second operation to retrieve list of album images if we think it's too heavy to retrieve all at once....
> Once we have this, we can start looking into applying more RESt style APIs and revisit how we can start taking advantage of http caching to improve performance of the overall client/server experience.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (PHOTARK-42) Improve PhotArk services by
refactoring current Services and Model Objects
Posted by "Luciano Resende (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PHOTARK-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Luciano Resende updated PHOTARK-42:
-----------------------------------
Summary: Improve PhotArk services by refactoring current Services and Model Objects (was: Improve PhotArk services refactoring Services and Model Objects)
> Improve PhotArk services by refactoring current Services and Model Objects
> --------------------------------------------------------------------------
>
> Key: PHOTARK-42
> URL: https://issues.apache.org/jira/browse/PHOTARK-42
> Project: PhotArk
> Issue Type: Improvement
> Components: PhoatArk Services
> Affects Versions: PhotArk M2
> Reporter: Luciano Resende
> Priority: Critical
> Fix For: PhotArk M3
>
>
> The current album service has grown out of control, and the client makes multiple calls to the service to retrieve multiple album information.
> We should start using more model/business objects, and stateless services that act on top of these objects.
> I'd like to propose we start defining Album as pure model/business objects that will have all album related info (e.g name, description, cover image url, etc) and same thing with Image.
> As for services, we should create a facade service to retrieve info in a more atomic way, e.g Gallery.getAlbum(albumName) retrieve a album model object with all info for the album at once. We might have a second operation to retrieve list of album images if we think it's too heavy to retrieve all at once....
> Once we have this, we can start looking into applying more RESt style APIs and revisit how we can start taking advantage of http caching to improve performance of the overall client/server experience.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (PHOTARK-42) Improve PhotArk services
by refactoring current Services and Model Objects
Posted by "Henry Saputra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PHOTARK-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867844#action_12867844 ]
Henry Saputra edited comment on PHOTARK-42 at 5/15/10 11:40 PM:
----------------------------------------------------------------
Instead of using TuscanyServletFilter I think we could create a context listener to have Node launcher dynamically to choose between jcr composite or file system.
was (Author: hsaputra):
Instead of using TuscanyFilter we should create photark context listener to have Node launcher dynamically to choose between jcr composite or file system.
> Improve PhotArk services by refactoring current Services and Model Objects
> --------------------------------------------------------------------------
>
> Key: PHOTARK-42
> URL: https://issues.apache.org/jira/browse/PHOTARK-42
> Project: PhotArk
> Issue Type: Improvement
> Components: PhoatArk Services
> Affects Versions: PhotArk M2
> Reporter: Luciano Resende
> Priority: Critical
> Fix For: PhotArk M3
>
>
> The current album service has grown out of control, and the client makes multiple calls to the service to retrieve multiple album information.
> We should start using more model/business objects, and stateless services that act on top of these objects.
> I'd like to propose we start defining Album as pure model/business objects that will have all album related info (e.g name, description, cover image url, etc) and same thing with Image.
> As for services, we should create a facade service to retrieve info in a more atomic way, e.g Gallery.getAlbum(albumName) retrieve a album model object with all info for the album at once. We might have a second operation to retrieve list of album images if we think it's too heavy to retrieve all at once....
> Once we have this, we can start looking into applying more RESt style APIs and revisit how we can start taking advantage of http caching to improve performance of the overall client/server experience.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.