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
<holivier.lis...@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/
