You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Olivier Heintz <ho...@nereide.biz> on 2012/03/21 20:13:36 UTC
Why Portlet is good for Losing Weight
The questions are :
===========
1) which solution "generate or need" less code
- PortalPage with multiple portlet
- screen with multiple subscreen and form
2) is migration generated regression or bugs
In my opinion:
=========
1)
- it's easier to use one portlet in multiple portalPage than a form in a
screen, because only portlet should be update when a add or update
action is done.
- with portletAttribute it's easier to define specifics portalPage
without new development, ex Supplier Profile page versus Employee Profile
- for business Analyst and developer, boundary is more clear with
portlet than sub-screen
- it's easier to do generic form using by multiple portlet, ex: file
content management (add, new version, update) form is used by
PartyContentFiles, WorkEffortContentFiles, ...
I know, most of the reasons is "ajax update" not portlet or sub-screen ;-)
2)
- migration can be done by extending existing form for the first
release, so not replace but added
- migration should change nothing in service only in user interface, so
correction is small
- bad point for portlet: sometime user have bug because there is a
wrong data in PortalPortlet entity (or portletAttributes or ..) so it's
more difficult for community to reproduce and to answer, if the current
default data is correct.
- Sometime migration help to clean some form, and so solve some bugs.
Ps: In the last 2 years, most our customer has been done with Portlet
(migrate from ofbiz screen or new one) most of these development are in
separate addons, one per "component-portlet migrate", and other for new
features.
We (company I'm workinf for) has never send their because we (and
specially me) had to time to review and clean the first addon which is
portletWidget. This task is done since today :-)
Each addon should be reviewed before being sent, but it will not be a
too large job each time,
Le 21/03/2012 17:48, Jacopo Cappellato a écrit :
> As a next step, after all these threads about the slim down will settle down, we should probably, as a community, start to prepare the plan of action, aka roadmap (we could use Jira for it): add there all the actionable tasks coming out of this discussions; then, in these mailing lists we should also start to discuss, as a community, what are the other priorities/goals for the next few months of the project. We should probably start slowly with some cleanup tasks and refactoring of old code, bug fixes etc... but we could also come up with some more interesting priorities (like JCR or reporting tools): then, based on the priorities identified by the community we will start to explore how to design them; if an agreement is found we will add the tasks to the roadmap as well; then we will have a clear and shared plan of actions to keep us all busy for a while
> If migration to portlets will be a priority item is something that should be discussed with the community: the community is small and it should stay focused on a few key goals at the time; if the community will decide that the migration to portlets is something desirable then we will definitely explore this concept.
>
> Jacopo
Re: Why Portlet is good for Losing Weight
Posted by Mansour Al Akeel <ma...@gmail.com>.
I know jetspeed-2, but nothing about the the screen-engine.
It will be good idea to integrate JS2. It's well maintained portal and
will save a lot of efforts.
I never through about integrating it directly, rather than using it
through XML RPC or JSON.
I don't have a clear plan, but if there is interest in the community
we can think about it.
Here's some brain storming:
1- Extend freemarker Portlet (or maybe XSLT), and give it an init pram
for the screen it has to render.
Note, I didn't see a freemarker portlet in the portlet bridges
project. But I don't imagine it's hard to create if needed.
However, since the screens are defined in xml it could be easier to
use xslt. For the decorators, jetspeed has separate decoration
mechanism http://portals.apache.org/jetspeed-2/tutorial/02/page-decoration.html
2- From the screen definition it will load an unique identifier.
3- change all the links and actions url back to the portlet instance.
If I know the screen-engine better, things will be easier. I am having
a look at it now.
One last thing is deployments. I didn't think about how each
application will be deployed.
If there's interest in the community, we can create a prototype
application. I know a member in
jetspeed team, at some point war very interested in integrating an
ERP. He may help.
On Thu, Mar 22, 2012 at 4:50 AM, Nicolas Malin
<ma...@librenberry.net> wrote:
> Hi Mansour,
>
> Do you know jetspeed2 for imaginea transparent integration with the
> screen-engine ?
>
> Nicolas
>
> Le 21/03/2012 20:49, Mansour Al Akeel a écrit :
>
>> Oliver,
>> would using an existing portal server be an option ?
>> There are portal servers out there (apache jetspeed2), that exist and
>> well maintained.
>> These servers are used in enterprises, to aggregate resource from
>> different applications and an ERP is a good candidate to use them.
>>
>>
>>
>> On Wed, Mar 21, 2012 at 3:13 PM, Olivier Heintz
>> <ho...@nereide.biz> wrote:
>>>
>>> The questions are :
>>> ===========
>>> 1) which solution "generate or need" less code
>>> - PortalPage with multiple portlet
>>> - screen with multiple subscreen and form
>>>
>>> 2) is migration generated regression or bugs
>>>
>>> In my opinion:
>>> =========
>>> 1)
>>> - it's easier to use one portlet in multiple portalPage than a form in a
>>> screen, because only portlet should be update when a add or update action
>>> is
>>> done.
>>> - with portletAttribute it's easier to define specifics portalPage
>>> without
>>> new development, ex Supplier Profile page versus Employee Profile
>>> - for business Analyst and developer, boundary is more clear with portlet
>>> than sub-screen
>>> - it's easier to do generic form using by multiple portlet, ex: file
>>> content
>>> management (add, new version, update) form is used by PartyContentFiles,
>>> WorkEffortContentFiles, ...
>>> I know, most of the reasons is "ajax update" not portlet or sub-screen
>>> ;-)
>>>
>>> 2)
>>> - migration can be done by extending existing form for the first release,
>>> so
>>> not replace but added
>>> - migration should change nothing in service only in user interface, so
>>> correction is small
>>> - bad point for portlet: sometime user have bug because there is a wrong
>>> data in PortalPortlet entity (or portletAttributes or ..) so it's more
>>> difficult for community to reproduce and to answer, if the current
>>> default
>>> data is correct.
>>> - Sometime migration help to clean some form, and so solve some bugs.
>>>
>>>
>>>
>>> Ps: In the last 2 years, most our customer has been done with Portlet
>>> (migrate from ofbiz screen or new one) most of these development are in
>>> separate addons, one per "component-portlet migrate", and other for new
>>> features.
>>> We (company I'm workinf for) has never send their because we (and
>>> specially
>>> me) had to time to review and clean the first addon which is
>>> portletWidget.
>>> This task is done since today :-)
>>> Each addon should be reviewed before being sent, but it will not be a too
>>> large job each time,
>>>
>>>
>>> Le 21/03/2012 17:48, Jacopo Cappellato a écrit :
>>>>
>>>> As a next step, after all these threads about the slim down will settle
>>>> down, we should probably, as a community, start to prepare the plan of
>>>> action, aka roadmap (we could use Jira for it): add there all the
>>>> actionable
>>>> tasks coming out of this discussions; then, in these mailing lists we
>>>> should
>>>> also start to discuss, as a community, what are the other
>>>> priorities/goals
>>>> for the next few months of the project. We should probably start slowly
>>>> with
>>>> some cleanup tasks and refactoring of old code, bug fixes etc... but we
>>>> could also come up with some more interesting priorities (like JCR or
>>>> reporting tools): then, based on the priorities identified by the
>>>> community
>>>> we will start to explore how to design them; if an agreement is found we
>>>> will add the tasks to the roadmap as well; then we will have a clear and
>>>> shared plan of actions to keep us all busy for a while
>>>> If migration to portlets will be a priority item is something that
>>>> should
>>>> be discussed with the community: the community is small and it should
>>>> stay
>>>> focused on a few key goals at the time; if the community will decide
>>>> that
>>>> the migration to portlets is something desirable then we will definitely
>>>> explore this concept.
>>>>
>>>> Jacopo
>
>
>
> --
> Nicolas MALIN
> Consultant
> Tél : 06.17.66.40.06
> Site projet : http://www.neogia.org/
> -------
> Société LibrenBerry
> Tél : 02.48.02.56.12
> Site : http://www.librenberry.net/
>
Re: Why Portlet is good for Losing Weight
Posted by Nicolas Malin <ma...@librenberry.net>.
Hi Mansour,
Do you know jetspeed2 for imaginea transparent integration with the
screen-engine ?
Nicolas
Le 21/03/2012 20:49, Mansour Al Akeel a écrit :
> Oliver,
> would using an existing portal server be an option ?
> There are portal servers out there (apache jetspeed2), that exist and
> well maintained.
> These servers are used in enterprises, to aggregate resource from
> different applications and an ERP is a good candidate to use them.
>
>
>
> On Wed, Mar 21, 2012 at 3:13 PM, Olivier Heintz
> <ho...@nereide.biz> wrote:
>> The questions are :
>> ===========
>> 1) which solution "generate or need" less code
>> - PortalPage with multiple portlet
>> - screen with multiple subscreen and form
>>
>> 2) is migration generated regression or bugs
>>
>> In my opinion:
>> =========
>> 1)
>> - it's easier to use one portlet in multiple portalPage than a form in a
>> screen, because only portlet should be update when a add or update action is
>> done.
>> - with portletAttribute it's easier to define specifics portalPage without
>> new development, ex Supplier Profile page versus Employee Profile
>> - for business Analyst and developer, boundary is more clear with portlet
>> than sub-screen
>> - it's easier to do generic form using by multiple portlet, ex: file content
>> management (add, new version, update) form is used by PartyContentFiles,
>> WorkEffortContentFiles, ...
>> I know, most of the reasons is "ajax update" not portlet or sub-screen ;-)
>>
>> 2)
>> - migration can be done by extending existing form for the first release, so
>> not replace but added
>> - migration should change nothing in service only in user interface, so
>> correction is small
>> - bad point for portlet: sometime user have bug because there is a wrong
>> data in PortalPortlet entity (or portletAttributes or ..) so it's more
>> difficult for community to reproduce and to answer, if the current default
>> data is correct.
>> - Sometime migration help to clean some form, and so solve some bugs.
>>
>>
>>
>> Ps: In the last 2 years, most our customer has been done with Portlet
>> (migrate from ofbiz screen or new one) most of these development are in
>> separate addons, one per "component-portlet migrate", and other for new
>> features.
>> We (company I'm workinf for) has never send their because we (and specially
>> me) had to time to review and clean the first addon which is portletWidget.
>> This task is done since today :-)
>> Each addon should be reviewed before being sent, but it will not be a too
>> large job each time,
>>
>>
>> Le 21/03/2012 17:48, Jacopo Cappellato a écrit :
>>> As a next step, after all these threads about the slim down will settle
>>> down, we should probably, as a community, start to prepare the plan of
>>> action, aka roadmap (we could use Jira for it): add there all the actionable
>>> tasks coming out of this discussions; then, in these mailing lists we should
>>> also start to discuss, as a community, what are the other priorities/goals
>>> for the next few months of the project. We should probably start slowly with
>>> some cleanup tasks and refactoring of old code, bug fixes etc... but we
>>> could also come up with some more interesting priorities (like JCR or
>>> reporting tools): then, based on the priorities identified by the community
>>> we will start to explore how to design them; if an agreement is found we
>>> will add the tasks to the roadmap as well; then we will have a clear and
>>> shared plan of actions to keep us all busy for a while
>>> If migration to portlets will be a priority item is something that should
>>> be discussed with the community: the community is small and it should stay
>>> focused on a few key goals at the time; if the community will decide that
>>> the migration to portlets is something desirable then we will definitely
>>> explore this concept.
>>>
>>> Jacopo
--
Nicolas MALIN
Consultant
Tél : 06.17.66.40.06
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : 02.48.02.56.12
Site : http://www.librenberry.net/
Re: Why Portlet is good for Losing Weight
Posted by Mansour Al Akeel <ma...@gmail.com>.
Oliver,
would using an existing portal server be an option ?
There are portal servers out there (apache jetspeed2), that exist and
well maintained.
These servers are used in enterprises, to aggregate resource from
different applications and an ERP is a good candidate to use them.
On Wed, Mar 21, 2012 at 3:13 PM, Olivier Heintz
<ho...@nereide.biz> wrote:
> The questions are :
> ===========
> 1) which solution "generate or need" less code
> - PortalPage with multiple portlet
> - screen with multiple subscreen and form
>
> 2) is migration generated regression or bugs
>
> In my opinion:
> =========
> 1)
> - it's easier to use one portlet in multiple portalPage than a form in a
> screen, because only portlet should be update when a add or update action is
> done.
> - with portletAttribute it's easier to define specifics portalPage without
> new development, ex Supplier Profile page versus Employee Profile
> - for business Analyst and developer, boundary is more clear with portlet
> than sub-screen
> - it's easier to do generic form using by multiple portlet, ex: file content
> management (add, new version, update) form is used by PartyContentFiles,
> WorkEffortContentFiles, ...
> I know, most of the reasons is "ajax update" not portlet or sub-screen ;-)
>
> 2)
> - migration can be done by extending existing form for the first release, so
> not replace but added
> - migration should change nothing in service only in user interface, so
> correction is small
> - bad point for portlet: sometime user have bug because there is a wrong
> data in PortalPortlet entity (or portletAttributes or ..) so it's more
> difficult for community to reproduce and to answer, if the current default
> data is correct.
> - Sometime migration help to clean some form, and so solve some bugs.
>
>
>
> Ps: In the last 2 years, most our customer has been done with Portlet
> (migrate from ofbiz screen or new one) most of these development are in
> separate addons, one per "component-portlet migrate", and other for new
> features.
> We (company I'm workinf for) has never send their because we (and specially
> me) had to time to review and clean the first addon which is portletWidget.
> This task is done since today :-)
> Each addon should be reviewed before being sent, but it will not be a too
> large job each time,
>
>
> Le 21/03/2012 17:48, Jacopo Cappellato a écrit :
>>
>> As a next step, after all these threads about the slim down will settle
>> down, we should probably, as a community, start to prepare the plan of
>> action, aka roadmap (we could use Jira for it): add there all the actionable
>> tasks coming out of this discussions; then, in these mailing lists we should
>> also start to discuss, as a community, what are the other priorities/goals
>> for the next few months of the project. We should probably start slowly with
>> some cleanup tasks and refactoring of old code, bug fixes etc... but we
>> could also come up with some more interesting priorities (like JCR or
>> reporting tools): then, based on the priorities identified by the community
>> we will start to explore how to design them; if an agreement is found we
>> will add the tasks to the roadmap as well; then we will have a clear and
>> shared plan of actions to keep us all busy for a while
>> If migration to portlets will be a priority item is something that should
>> be discussed with the community: the community is small and it should stay
>> focused on a few key goals at the time; if the community will decide that
>> the migration to portlets is something desirable then we will definitely
>> explore this concept.
>>
>> Jacopo