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
