Re: Conditional seed data loading

[Ean Schuessler]

Hans Bakker wrote:
> Yes we should seriously look at this. These "gadgets" are based on the
> apache shindig (http://incubator.apache.org/shindig/) project. perhaps
> we can also use this in ofbiz? Shindig is an implementation of the
> opensocial (http://code.google.com/apis/opensocial/) standard
> 
> so ofbiz portlets can be used in other systems and viceversa?

I think this goes beyond MyProfile. OpenSocial is more about
relationships between containers that provide a notion of identity. The
system was developed for MySpace/Facebook style relationships but it
could have major implications for exchanging corporate role information
between companies.

>From the MyPortal perspective, GoogleGadgets is more what you are
interested in. These could also have a larger implication from a widget
API point of view. It might be useful to have insertion points for
micro-portlets in any screen in the system.

Re: Conditional seed data loading

[Tim Ruppert]

That's really interesting.  As a power usage - the Atlassian tools 
implementation of these "gadgets" is really useful and powerful in their tools. 
 

Cheers,
Ruppert
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com

o:801.649.6594
f:801.649.6595

On Jan 1, 2010, at 6:06 PM, Hans Bakker wrote:

> Yes we should seriously look at this. These "gadgets" are based on the
> apache shindig (http://incubator.apache.org/shindig/) project. perhaps
> we can also use this in ofbiz? Shindig is an implementation of the
> opensocial (http://code.google.com/apis/opensocial/) standard
> 
> so ofbiz portlets can be used in other systems and viceversa?
> 
> Regards,
> Hans
> 
> 
> On Fri, 2010-01-01 at 22:07 +0100, Bruno Busco wrote:
>> When Portlets were introduced in OFBiz I had in mind what I was
>> familiar with using JIRA:
>> http://www.atlassian.com/software/jira/docs/v3.12/portlets_summary.html
>> This was also why I initially called "Dashboard" the first portalPage
>> that is actually in the OFBiz example.
>> 
>> In the latest JIRA version 4.0 they are migrating from Portlets to
>> Gadgets http://confluence.atlassian.com/display/JIRA/Using+Dashboard+Gadgets
>> and still calling "Dashboard pages" what is our portalPages.
>> 
>> -Bruno
>>> 
> -- 
> Antwebsystems.com: Quality OFBiz services for competitive rates
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: Conditional seed data loading

[Hans Bakker]

Yes we should seriously look at this. These "gadgets" are based on the
apache shindig (http://incubator.apache.org/shindig/) project. perhaps
we can also use this in ofbiz? Shindig is an implementation of the
opensocial (http://code.google.com/apis/opensocial/) standard

so ofbiz portlets can be used in other systems and viceversa?

Regards,
Hans


On Fri, 2010-01-01 at 22:07 +0100, Bruno Busco wrote:
> When Portlets were introduced in OFBiz I had in mind what I was
> familiar with using JIRA:
> http://www.atlassian.com/software/jira/docs/v3.12/portlets_summary.html
> This was also why I initially called "Dashboard" the first portalPage
> that is actually in the OFBiz example.
> 
> In the latest JIRA version 4.0 they are migrating from Portlets to
> Gadgets http://confluence.atlassian.com/display/JIRA/Using+Dashboard+Gadgets
> and still calling "Dashboard pages" what is our portalPages.
> 
> -Bruno
> >
-- 
Antwebsystems.com: Quality OFBiz services for competitive rates

Re: Conditional seed data loading

[Bruno Busco]

When Portlets were introduced in OFBiz I had in mind what I was
familiar with using JIRA:
http://www.atlassian.com/software/jira/docs/v3.12/portlets_summary.html
This was also why I initially called "Dashboard" the first portalPage
that is actually in the OFBiz example.

In the latest JIRA version 4.0 they are migrating from Portlets to
Gadgets http://confluence.atlassian.com/display/JIRA/Using+Dashboard+Gadgets
and still calling "Dashboard pages" what is our portalPages.

-Bruno

2010/1/1 Tim Ruppert :
> +1 - thanks for bringing sanity back to the discussion.  What shall all of 
> these lost souls in the PHP world with with their creations?  
> http://www.hotscripts.com/category/php/scripts-programs/portal-systems/
>
> Cheers,
> Ruppert
> --
> Tim Ruppert
> HotWax Media
> http://www.hotwaxmedia.com
>
> o:801.649.6594
> f:801.649.6595
>
> On Dec 31, 2009, at 10:28 AM, David E Jones wrote:
>
>>
>> Bring confusion in the future? That's like saying you shouldn't use the term 
>> object-relational mapping unless you're talking about JPA.
>>
>> Just like object-relational mapping is a general term with many variations 
>> and implementations, and supporting the JPA interfaces is simply a feature 
>> of some of those implementations, portal and portlet are also general terms 
>> with many variations and implementations, and only some of them support the 
>> JSR 168 specification.
>>
>> Should we then say that portal/portlet software not written in Java should 
>> not use those terms?
>>
>> If so, which terms should those unfortunate souls use to describe their 
>> creations?
>>
>> -David
>>
>>
>> On Dec 31, 2009, at 8:48 AM, Jacques Le Roux wrote:
>>
>>> I agree with Ruth, this will (and has already) certainly bring some 
>>> confusion in future.
>>>
>>> Jacques
>>>
>>> From: "Ruth Hoffman" 
 Hi David:
 IMO the term "portlet" should only be applied to JSR 168/268 compliant 
 code.

 Regards,
 Ruth

 David E Jones wrote:
> MyPortal still needs a lot of work.
>
> It should really be just the shell of the portal and include only a very 
> few portlets that are part of the framework.
>
> Higher level components, including applications components, can have 
> their own portlets that appear in MyPortal by having data in seed/etc 
> data files, and that data will tell MyPortal about these portlets.
>
> OOTB the MyPortal stuff shouldn't know anything about any portlets (other 
> than a few basic framework ones). At runtime MyPortal will look for 
> information about other portlets, but that information should come only 
> from the higher level components where the portlets themselves live.
>
> -David
>
>
> On Dec 31, 2009, at 4:50 AM, Bruno Busco wrote:
>
>
>> That's true, it would be still a dependence.
>>
>> Anyway, in this case the MyPortal is considered to be dependent from
>> all other components (because it "mounts" portlets defined by all
>> other components in the default portalPages).
>> It should be possible to use the MyPortal component even if one of the
>> other components is not used.
>>
>> I think a different logic is needed here.
>>
>> -Bruno
>>
>> 2009/12/31 David E Jones :
>>
>>> That still represents a dependency on the other component.
>>>
>>> Lower level components should not even have anything that represents an 
>>> awareness of a higher level component.
>>>
>>> The solution, and the only solution, is to move the data to the higher 
>>> level components. It's that simple.
>>>
>>> -David
>>>
>>>
>>> On Dec 30, 2009, at 5:54 PM, Bruno Busco wrote:
>>>
>>>
 Hi,
 the MyPortal component has many seed data that create a dependence
 from many other components.
 This is done because the seed data create the default MyPortal
 portalPages that include several portlets from all other components.

 For example:
  >>> portalPortletId="SystemInfoNotes" portletSeqId="1"
 columnSeqId="1" sequenceNum="0"/>
  >>> portalPortletId="SystemInfoStatus" portletSeqId="1"
 columnSeqId="1" sequenceNum="1"/>
  >>> portalPortletId="Calendar" portletSeqId="1" columnSeqId="1"
 sequenceNum="2"/>
  >>> portalPortletId="INCOM_CUST_REQUESTS" portletSeqId="1"
 columnSeqId="1" sequenceNum="0"/>
  >>> portalPortletId="MyCommunications" portletSeqId="1"
 columnSeqId="1" sequenceNum="1"/>
  >>> portalPortletId="party" portletSeqId="1" columnSeqId="1"
 sequenceNum="0"/>
  >>> portalPortletId="partyRelContacts" portletSeqId="1"
 columnSeqId="1" sequenceNum="1"/>
  >>> portalPortletId="partyRelAccounts" portletSeqId="1"
 columnSeqId="1" sequence

Re: Conditional seed data loading

[Tim Ruppert]

+1 - thanks for bringing sanity back to the discussion.  What shall all of 
these lost souls in the PHP world with with their creations?  
http://www.hotscripts.com/category/php/scripts-programs/portal-systems/

Cheers,
Ruppert
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com

o:801.649.6594
f:801.649.6595

On Dec 31, 2009, at 10:28 AM, David E Jones wrote:

> 
> Bring confusion in the future? That's like saying you shouldn't use the term 
> object-relational mapping unless you're talking about JPA.
> 
> Just like object-relational mapping is a general term with many variations 
> and implementations, and supporting the JPA interfaces is simply a feature of 
> some of those implementations, portal and portlet are also general terms with 
> many variations and implementations, and only some of them support the JSR 
> 168 specification.
> 
> Should we then say that portal/portlet software not written in Java should 
> not use those terms?
> 
> If so, which terms should those unfortunate souls use to describe their 
> creations?
> 
> -David
> 
> 
> On Dec 31, 2009, at 8:48 AM, Jacques Le Roux wrote:
> 
>> I agree with Ruth, this will (and has already) certainly bring some 
>> confusion in future.
>> 
>> Jacques
>> 
>> From: "Ruth Hoffman" 
>>> Hi David:
>>> IMO the term "portlet" should only be applied to JSR 168/268 compliant code.
>>> 
>>> Regards,
>>> Ruth
>>> 
>>> David E Jones wrote:
 MyPortal still needs a lot of work.
 
 It should really be just the shell of the portal and include only a very 
 few portlets that are part of the framework.
 
 Higher level components, including applications components, can have their 
 own portlets that appear in MyPortal by having data in seed/etc data 
 files, and that data will tell MyPortal about these portlets.
 
 OOTB the MyPortal stuff shouldn't know anything about any portlets (other 
 than a few basic framework ones). At runtime MyPortal will look for 
 information about other portlets, but that information should come only 
 from the higher level components where the portlets themselves live.
 
 -David
 
 
 On Dec 31, 2009, at 4:50 AM, Bruno Busco wrote:
 
 
> That's true, it would be still a dependence.
> 
> Anyway, in this case the MyPortal is considered to be dependent from
> all other components (because it "mounts" portlets defined by all
> other components in the default portalPages).
> It should be possible to use the MyPortal component even if one of the
> other components is not used.
> 
> I think a different logic is needed here.
> 
> -Bruno
> 
> 2009/12/31 David E Jones :
> 
>> That still represents a dependency on the other component.
>> 
>> Lower level components should not even have anything that represents an 
>> awareness of a higher level component.
>> 
>> The solution, and the only solution, is to move the data to the higher 
>> level components. It's that simple.
>> 
>> -David
>> 
>> 
>> On Dec 30, 2009, at 5:54 PM, Bruno Busco wrote:
>> 
>> 
>>> Hi,
>>> the MyPortal component has many seed data that create a dependence
>>> from many other components.
>>> This is done because the seed data create the default MyPortal
>>> portalPages that include several portlets from all other components.
>>> 
>>> For example:
>>>  >> portalPortletId="SystemInfoNotes" portletSeqId="1"
>>> columnSeqId="1" sequenceNum="0"/>
>>>  >> portalPortletId="SystemInfoStatus" portletSeqId="1"
>>> columnSeqId="1" sequenceNum="1"/>
>>>  >> portalPortletId="Calendar" portletSeqId="1" columnSeqId="1"
>>> sequenceNum="2"/>
>>>  >> portalPortletId="INCOM_CUST_REQUESTS" portletSeqId="1"
>>> columnSeqId="1" sequenceNum="0"/>
>>>  >> portalPortletId="MyCommunications" portletSeqId="1"
>>> columnSeqId="1" sequenceNum="1"/>
>>>  >> portalPortletId="party" portletSeqId="1" columnSeqId="1"
>>> sequenceNum="0"/>
>>>  >> portalPortletId="partyRelContacts" portletSeqId="1"
>>> columnSeqId="1" sequenceNum="1"/>
>>>  >> portalPortletId="partyRelAccounts" portletSeqId="1"
>>> columnSeqId="1" sequenceNum="2"/>
>>>  >> portalPortletId="contact" portletSeqId="1" columnSeqId="1"
>>> sequenceNum="3"/>
>>>  >> portalPortletId="LoyaltyPoints" portletSeqId="1"
>>> columnSeqId="1" sequenceNum="4"/>
>>>  >> portalPortletId="PaymentMethods" portletSeqId="1"
>>> columnSeqId="1" sequenceNum="5"/>
>>>  >> portalPortletId="AvsSettings" portletSeqId="1" columnSeqId="1"
>>> sequenceNum="6"/>
>>>  >> portalPortletId="UserLogin" portletSeqId="1" columnSeqId="2"
>>> sequenceNum="1"/>
>>>  >> portalPortletId="Attributes" port

Re: Conditional seed data loading

[Jacques Le Roux]

Sorry Michael,

So you idea is to propose to use mahsups instead of standard portlets (already 2 std actually, even 3 with JSR enhancements), that's 
it?


FYO: there has been already a proposition on Mashup
http://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document#NewFeaturesRoadmap-LivingDocument-IntroduceMashups

Jacques

From: "Michael Xu (xudong)" 

Maybe we can take a look at mashup, which is not that heavy as portlets.

http://en.wikipedia.org/wiki/Mashup_(web_application_hybrid)

--
Regards,
Michael Xu (xudong)
www.wizitsoft.com | Office: (8610) 6267 0615 ext 806 | Mobile: (86) 135 0135
9807 | Fax: (8610) 62670096


On Fri, Jan 1, 2010 at 2:37 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Actually we would just have to change the name at the surface, from a
marketing POV if you prefer. No need to change underneath.
But sincerely I have not much time for that... Where is it used in
documentation which could induce new users in error?


Jacques

From: "Ruth Hoffman" 


Hi Jacques:
IMO, it is a big deal. When someone is looking at OFBiz for an enterprise
solution and the competition is Jetspeed, Liferay, Websphere etc., we should
be clear  that when the OFBiz project says "Portal" it does not mean what
everyone else "thinks it means". It is misleading.

Just to be clear: I don't think OFBiz needs a JSR compliant portal server.
In my experience, portal servers are bloated and overrated and have limited
use.

Maybe we could take a little survey - do some marketing - and come up with
another label for these features/functions?

Just a thought.
Ruth

Jacques Le Roux wrote:


From: "David E Jones" 


Bring confusion in the future? That's like saying you shouldn't use the
term object-relational mapping unless you're talking about JPA.

Just like object-relational mapping is a general term with many
variations and implementations, and supporting the JPA interfaces is simply
a feature of some of those implementations, portal and portlet are also
general terms with many variations and implementations, and only some of
them support the JSR 168 specification.

Should we then say that portal/portlet software not written in Java
should not use those terms?

If so, which terms should those unfortunate souls use to describe their
creations?



OFBiz-portlets and OFBiz-portal ? Not a big deal anyway, just that some
people think they will be able to embed some external portlets in OFBiz and
are dissapointed.

Jacques

 -David



On Dec 31, 2009, at 8:48 AM, Jacques Le Roux wrote:

 I agree with Ruth, this will (and has already) certainly bring some

confusion in future.

Jacques

From: "Ruth Hoffman" 


Hi David:
IMO the term "portlet" should only be applied to JSR 168/268 compliant
code.

Regards,
Ruth

David E Jones wrote:


MyPortal still needs a lot of work.

It should really be just the shell of the portal and include only a
very few portlets that are part of the framework.

Higher level components, including applications components, can have
their own portlets that appear in MyPortal by having data in seed/etc data
files, and that data will tell MyPortal about these portlets.

OOTB the MyPortal stuff shouldn't know anything about any portlets
(other than a few basic framework ones). At runtime MyPortal will look for
information about other portlets, but that information should come only from
the higher level components where the portlets themselves live.

-David


On Dec 31, 2009, at 4:50 AM, Bruno Busco wrote:


 That's true, it would be still a dependence.


Anyway, in this case the MyPortal is considered to be dependent from
all other components (because it "mounts" portlets defined by all
other components in the default portalPages).
It should be possible to use the MyPortal component even if one of
the
other components is not used.

I think a different logic is needed here.

-Bruno

2009/12/31 David E Jones :

 That still represents a dependency on the other component.


Lower level components should not even have anything that
represents an awareness of a higher level component.

The solution, and the only solution, is to move the data to the
higher level components. It's that simple.

-David


On Dec 30, 2009, at 5:54 PM, Bruno Busco wrote:


 Hi,

the MyPortal component has many seed data that create a dependence
from many other components.
This is done because the seed data create the default MyPortal
portalPages that include several portlets from all other
components.

For example:
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

How can we have a conditional seed data loading that would load
only
seed data for the portlets really available in the system?
I mean, could we have something like this:


 
 


or is there any other tecnique to do this?

Many thanks,
Bruno

Re: Conditional seed data loading

[Michael Xu (xudong)]

Maybe we can take a look at mashup, which is not that heavy as portlets.

http://en.wikipedia.org/wiki/Mashup_(web_application_hybrid)
 
--
Regards,
Michael Xu (xudong)
www.wizitsoft.com | Office: (8610) 6267 0615 ext 806 | Mobile: (86) 135 0135
9807 | Fax: (8610) 62670096


On Fri, Jan 1, 2010 at 2:37 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Actually we would just have to change the name at the surface, from a
> marketing POV if you prefer. No need to change underneath.
> But sincerely I have not much time for that... Where is it used in
> documentation which could induce new users in error?
>
>
> Jacques
>
> From: "Ruth Hoffman" 
>
>> Hi Jacques:
>> IMO, it is a big deal. When someone is looking at OFBiz for an enterprise
>> solution and the competition is Jetspeed, Liferay, Websphere etc., we should
>> be clear  that when the OFBiz project says "Portal" it does not mean what
>> everyone else "thinks it means". It is misleading.
>>
>> Just to be clear: I don't think OFBiz needs a JSR compliant portal server.
>> In my experience, portal servers are bloated and overrated and have limited
>> use.
>>
>> Maybe we could take a little survey - do some marketing - and come up with
>> another label for these features/functions?
>>
>> Just a thought.
>> Ruth
>>
>> Jacques Le Roux wrote:
>>
>>> From: "David E Jones" 
>>>
 Bring confusion in the future? That's like saying you shouldn't use the
 term object-relational mapping unless you're talking about JPA.

 Just like object-relational mapping is a general term with many
 variations and implementations, and supporting the JPA interfaces is simply
 a feature of some of those implementations, portal and portlet are also
 general terms with many variations and implementations, and only some of
 them support the JSR 168 specification.

 Should we then say that portal/portlet software not written in Java
 should not use those terms?

 If so, which terms should those unfortunate souls use to describe their
 creations?

>>>
>>> OFBiz-portlets and OFBiz-portal ? Not a big deal anyway, just that some
>>> people think they will be able to embed some external portlets in OFBiz and
>>> are dissapointed.
>>>
>>> Jacques
>>>
>>>  -David


 On Dec 31, 2009, at 8:48 AM, Jacques Le Roux wrote:

  I agree with Ruth, this will (and has already) certainly bring some
> confusion in future.
>
> Jacques
>
> From: "Ruth Hoffman" 
>
>> Hi David:
>> IMO the term "portlet" should only be applied to JSR 168/268 compliant
>> code.
>>
>> Regards,
>> Ruth
>>
>> David E Jones wrote:
>>
>>> MyPortal still needs a lot of work.
>>>
>>> It should really be just the shell of the portal and include only a
>>> very few portlets that are part of the framework.
>>>
>>> Higher level components, including applications components, can have
>>> their own portlets that appear in MyPortal by having data in seed/etc 
>>> data
>>> files, and that data will tell MyPortal about these portlets.
>>>
>>> OOTB the MyPortal stuff shouldn't know anything about any portlets
>>> (other than a few basic framework ones). At runtime MyPortal will look 
>>> for
>>> information about other portlets, but that information should come only 
>>> from
>>> the higher level components where the portlets themselves live.
>>>
>>> -David
>>>
>>>
>>> On Dec 31, 2009, at 4:50 AM, Bruno Busco wrote:
>>>
>>>
>>>  That's true, it would be still a dependence.

 Anyway, in this case the MyPortal is considered to be dependent from
 all other components (because it "mounts" portlets defined by all
 other components in the default portalPages).
 It should be possible to use the MyPortal component even if one of
 the
 other components is not used.

 I think a different logic is needed here.

 -Bruno

 2009/12/31 David E Jones :

  That still represents a dependency on the other component.
>
> Lower level components should not even have anything that
> represents an awareness of a higher level component.
>
> The solution, and the only solution, is to move the data to the
> higher level components. It's that simple.
>
> -David
>
>
> On Dec 30, 2009, at 5:54 PM, Bruno Busco wrote:
>
>
>  Hi,
>> the MyPortal component has many seed data that create a dependence
>> from many other components.
>> This is done because the seed data create the default MyPortal
>> portalPages that include several portlets from all other
>> components.
>>
>> For example:

Re: Conditional seed data loading

[Jacques Le Roux]

Actually we would just have to change the name at the surface, from a marketing 
POV if you prefer. No need to change underneath.
But sincerely I have not much time for that... Where is it used in 
documentation which could induce new users in error?

Jacques

From: "Ruth Hoffman" 

Hi Jacques:
IMO, it is a big deal. When someone is looking at OFBiz for an 
enterprise solution and the competition is Jetspeed, Liferay, Websphere 
etc., we should be clear  that when the OFBiz project says "Portal" it 
does not mean what everyone else "thinks it means". It is misleading.


Just to be clear: I don't think OFBiz needs a JSR compliant portal 
server. In my experience, portal servers are bloated and overrated and 
have limited use.


Maybe we could take a little survey - do some marketing - and come up 
with another label for these features/functions?


Just a thought.
Ruth

Jacques Le Roux wrote:

From: "David E Jones" 
Bring confusion in the future? That's like saying you shouldn't use 
the term object-relational mapping unless you're talking about JPA.


Just like object-relational mapping is a general term with many 
variations and implementations, and supporting the JPA interfaces is 
simply a feature of some of those implementations, portal and portlet 
are also general terms with many variations and implementations, and 
only some of them support the JSR 168 specification.


Should we then say that portal/portlet software not written in Java 
should not use those terms?


If so, which terms should those unfortunate souls use to describe 
their creations?


OFBiz-portlets and OFBiz-portal ? Not a big deal anyway, just that 
some people think they will be able to embed some external portlets in 
OFBiz and are dissapointed.


Jacques


-David


On Dec 31, 2009, at 8:48 AM, Jacques Le Roux wrote:

I agree with Ruth, this will (and has already) certainly bring some 
confusion in future.


Jacques

From: "Ruth Hoffman" 

Hi David:
IMO the term "portlet" should only be applied to JSR 168/268 
compliant code.


Regards,
Ruth

David E Jones wrote:

MyPortal still needs a lot of work.

It should really be just the shell of the portal and include only 
a very few portlets that are part of the framework.


Higher level components, including applications components, can 
have their own portlets that appear in MyPortal by having data in 
seed/etc data files, and that data will tell MyPortal about these 
portlets.


OOTB the MyPortal stuff shouldn't know anything about any portlets 
(other than a few basic framework ones). At runtime MyPortal will 
look for information about other portlets, but that information 
should come only from the higher level components where the 
portlets themselves live.


-David


On Dec 31, 2009, at 4:50 AM, Bruno Busco wrote:



That's true, it would be still a dependence.

Anyway, in this case the MyPortal is considered to be dependent from
all other components (because it "mounts" portlets defined by all
other components in the default portalPages).
It should be possible to use the MyPortal component even if one 
of the

other components is not used.

I think a different logic is needed here.

-Bruno

2009/12/31 David E Jones :


That still represents a dependency on the other component.

Lower level components should not even have anything that 
represents an awareness of a higher level component.


The solution, and the only solution, is to move the data to the 
higher level components. It's that simple.


-David


On Dec 30, 2009, at 5:54 PM, Bruno Busco wrote:



Hi,
the MyPortal component has many seed data that create a dependence
from many other components.
This is done because the seed data create the default MyPortal
portalPages that include several portlets from all other 
components.


For example:
  
  
  portalPortletId="Calendar" portletSeqId="1" 
columnSeqId="1"

sequenceNum="2"/>
  
  
  
  
  
  
  
  
  portalPortletId="AvsSettings" portletSeqId="1" 
columnSeqId="1"

sequenceNum="6"/>
  portalPortletId="UserLogin" portletSeqId="1" 
columnSeqId="2"

sequenceNum="1"/>
  portalPortletId="Attributes" portletSeqId="1" 
columnSeqId="2"

sequenceNum="2"/>
  
  
  
  
  
  
  
  portalPortletId="mytimesheet" portletSeqId="1" 
columnSeqId="1"

sequenceNum="0"/>
  

How can we have a conditional seed data loading that would load 
only

seed data for the portlets really available in the system?
I mean, could we have something like this:


  portalPortletId="mytimesheet" portletSeqId="1" 
columnSeqId="1"

sequenceNum="0"/>
  


or is there any other tecnique to do this?

Many thanks,
Bruno

Re: Conditional seed data loading

[Jacques Le Roux]

BTW there is also the WSRP standard  (I did not know about it)
http://en.wikipedia.org/wiki/Web_Services_for_Remote_Portlets

Jacques

From: "Ruth Hoffman" 

Hi David:
IMO the term "portlet" should only be applied to JSR 168/268 compliant code.

Regards,
Ruth

David E Jones wrote:

MyPortal still needs a lot of work.

It should really be just the shell of the portal and include only a very few 
portlets that are part of the framework.

Higher level components, including applications components, can have their own portlets that appear in MyPortal by having data in 
seed/etc data files, and that data will tell MyPortal about these portlets.


OOTB the MyPortal stuff shouldn't know anything about any portlets (other than a few basic framework ones). At runtime MyPortal 
will look for information about other portlets, but that information should come only from the higher level components where the 
portlets themselves live.


-David


On Dec 31, 2009, at 4:50 AM, Bruno Busco wrote:



That's true, it would be still a dependence.

Anyway, in this case the MyPortal is considered to be dependent from
all other components (because it "mounts" portlets defined by all
other components in the default portalPages).
It should be possible to use the MyPortal component even if one of the
other components is not used.

I think a different logic is needed here.

-Bruno

2009/12/31 David E Jones :


That still represents a dependency on the other component.

Lower level components should not even have anything that represents an 
awareness of a higher level component.

The solution, and the only solution, is to move the data to the higher level 
components. It's that simple.

-David


On Dec 30, 2009, at 5:54 PM, Bruno Busco wrote:



Hi,
the MyPortal component has many seed data that create a dependence
from many other components.
This is done because the seed data create the default MyPortal
portalPages that include several portlets from all other components.

For example:
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   

How can we have a conditional seed data loading that would load only
seed data for the portlets really available in the system?
I mean, could we have something like this:


   
   


or is there any other tecnique to do this?

Many thanks,
Bruno

Re: Conditional seed data loading

[Hans Bakker]

probably all replaced with opensocial: http://www.opensocial.org/?


On Thu, 2009-12-31 at 12:17 -0600, Adam Heath wrote:
> David E Jones wrote:
> > Bring confusion in the future? That's like saying you shouldn't use
> > the term object-relational mapping unless you're talking about JPA.
> > 
> > Just like object-relational mapping is a general term with many
> > variations and implementations, and supporting the JPA interfaces is
> > simply a feature of some of those implementations, portal and
> > portlet are also general terms with many variations and
> > implementations, and only some of them support the JSR 168
> > specification.
> >
> > Should we then say that portal/portlet software not written in Java
> > should not use those terms?
> > 
> > If so, which terms should those unfortunate souls use to describe
> > their creations?
> 
> You should go work for sun(soon to be oracle) marketing.  They'd love
> to have you on board.
-- 
Antwebsystems.com: Quality OFBiz services for competitive rates

Re: Conditional seed data loading

[Adam Heath]

David E Jones wrote:
> Bring confusion in the future? That's like saying you shouldn't use
> the term object-relational mapping unless you're talking about JPA.
> 
> Just like object-relational mapping is a general term with many
> variations and implementations, and supporting the JPA interfaces is
> simply a feature of some of those implementations, portal and
> portlet are also general terms with many variations and
> implementations, and only some of them support the JSR 168
> specification.
>
> Should we then say that portal/portlet software not written in Java
> should not use those terms?
> 
> If so, which terms should those unfortunate souls use to describe
> their creations?

You should go work for sun(soon to be oracle) marketing.  They'd love
to have you on board.

Re: Conditional seed data loading

[Ruth Hoffman]

Hi Jacques:
IMO, it is a big deal. When someone is looking at OFBiz for an 
enterprise solution and the competition is Jetspeed, Liferay, Websphere 
etc., we should be clear  that when the OFBiz project says "Portal" it 
does not mean what everyone else "thinks it means". It is misleading.


Just to be clear: I don't think OFBiz needs a JSR compliant portal 
server. In my experience, portal servers are bloated and overrated and 
have limited use.


Maybe we could take a little survey - do some marketing - and come up 
with another label for these features/functions?


Just a thought.
Ruth

Jacques Le Roux wrote:

From: "David E Jones" 
Bring confusion in the future? That's like saying you shouldn't use 
the term object-relational mapping unless you're talking about JPA.


Just like object-relational mapping is a general term with many 
variations and implementations, and supporting the JPA interfaces is 
simply a feature of some of those implementations, portal and portlet 
are also general terms with many variations and implementations, and 
only some of them support the JSR 168 specification.


Should we then say that portal/portlet software not written in Java 
should not use those terms?


If so, which terms should those unfortunate souls use to describe 
their creations?


OFBiz-portlets and OFBiz-portal ? Not a big deal anyway, just that 
some people think they will be able to embed some external portlets in 
OFBiz and are dissapointed.


Jacques


-David


On Dec 31, 2009, at 8:48 AM, Jacques Le Roux wrote:

I agree with Ruth, this will (and has already) certainly bring some 
confusion in future.


Jacques

From: "Ruth Hoffman" 

Hi David:
IMO the term "portlet" should only be applied to JSR 168/268 
compliant code.


Regards,
Ruth

David E Jones wrote:

MyPortal still needs a lot of work.

It should really be just the shell of the portal and include only 
a very few portlets that are part of the framework.


Higher level components, including applications components, can 
have their own portlets that appear in MyPortal by having data in 
seed/etc data files, and that data will tell MyPortal about these 
portlets.


OOTB the MyPortal stuff shouldn't know anything about any portlets 
(other than a few basic framework ones). At runtime MyPortal will 
look for information about other portlets, but that information 
should come only from the higher level components where the 
portlets themselves live.


-David


On Dec 31, 2009, at 4:50 AM, Bruno Busco wrote:



That's true, it would be still a dependence.

Anyway, in this case the MyPortal is considered to be dependent from
all other components (because it "mounts" portlets defined by all
other components in the default portalPages).
It should be possible to use the MyPortal component even if one 
of the

other components is not used.

I think a different logic is needed here.

-Bruno

2009/12/31 David E Jones :


That still represents a dependency on the other component.

Lower level components should not even have anything that 
represents an awareness of a higher level component.


The solution, and the only solution, is to move the data to the 
higher level components. It's that simple.


-David


On Dec 30, 2009, at 5:54 PM, Bruno Busco wrote:



Hi,
the MyPortal component has many seed data that create a dependence
from many other components.
This is done because the seed data create the default MyPortal
portalPages that include several portlets from all other 
components.


For example:
  
  
  portalPortletId="Calendar" portletSeqId="1" 
columnSeqId="1"

sequenceNum="2"/>
  
  
  
  
  
  
  
  
  portalPortletId="AvsSettings" portletSeqId="1" 
columnSeqId="1"

sequenceNum="6"/>
  portalPortletId="UserLogin" portletSeqId="1" 
columnSeqId="2"

sequenceNum="1"/>
  portalPortletId="Attributes" portletSeqId="1" 
columnSeqId="2"

sequenceNum="2"/>
  
  
  
  
  
  
  
  portalPortletId="mytimesheet" portletSeqId="1" 
columnSeqId="1"

sequenceNum="0"/>
  

How can we have a conditional seed data loading that would load 
only

seed data for the portlets really available in the system?
I mean, could we have something like this:


  portalPortletId="mytimesheet" portletSeqId="1" 
columnSeqId="1"

sequenceNum="0"/>
  


or is there any other tecnique to do this?

Many thanks,
Bruno

Re: Conditional seed data loading

[Ruth Hoffman]

Hi David:

David E Jones wrote:

Bring confusion in the future? That's like saying you shouldn't use the term 
object-relational mapping unless you're talking about JPA.

  
I beg to differ. "Portlets" and "Portals" have clear definitions 
recognized in the Java community: JSR 168/268. Regardless of when these 
terms were coined, they now have a brand and the OFBiz community's use 
of them interchangeably with OFBiz features/functions is confusing at 
best and misleading at worst.

Just like object-relational mapping is a general term with many variations and 
implementations, and supporting the JPA interfaces is simply a feature of some 
of those implementations, portal and portlet are also general terms with many 
variations and implementations, and only some of them support the JSR 168 
specification.

Should we then say that portal/portlet software not written in Java should not 
use those terms?
  
If so, which terms should those unfortunate souls use to describe their creations?


  
-David



On Dec 31, 2009, at 8:48 AM, Jacques Le Roux wrote:

  

I agree with Ruth, this will (and has already) certainly bring some confusion 
in future.

Jacques

From: "Ruth Hoffman" 


Hi David:
IMO the term "portlet" should only be applied to JSR 168/268 compliant code.

Regards,
Ruth

David E Jones wrote:
  

MyPortal still needs a lot of work.

It should really be just the shell of the portal and include only a very few 
portlets that are part of the framework.

Higher level components, including applications components, can have their own 
portlets that appear in MyPortal by having data in seed/etc data files, and 
that data will tell MyPortal about these portlets.

OOTB the MyPortal stuff shouldn't know anything about any portlets (other than 
a few basic framework ones). At runtime MyPortal will look for information 
about other portlets, but that information should come only from the higher 
level components where the portlets themselves live.

-David


On Dec 31, 2009, at 4:50 AM, Bruno Busco wrote:




That's true, it would be still a dependence.

Anyway, in this case the MyPortal is considered to be dependent from
all other components (because it "mounts" portlets defined by all
other components in the default portalPages).
It should be possible to use the MyPortal component even if one of the
other components is not used.

I think a different logic is needed here.

-Bruno

2009/12/31 David E Jones :

  

That still represents a dependency on the other component.

Lower level components should not even have anything that represents an 
awareness of a higher level component.

The solution, and the only solution, is to move the data to the higher level 
components. It's that simple.

-David


On Dec 30, 2009, at 5:54 PM, Bruno Busco wrote:




Hi,
the MyPortal component has many seed data that create a dependence
from many other components.
This is done because the seed data create the default MyPortal
portalPages that include several portlets from all other components.

For example:
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  

How can we have a conditional seed data loading that would load only
seed data for the portlets really available in the system?
I mean, could we have something like this:


  
  


or is there any other tecnique to do this?

Many thanks,
Bruno

  







  

Re: Conditional seed data loading

[Jacques Le Roux]

From: "David E Jones" 
Bring confusion in the future? That's like saying you shouldn't use the term object-relational mapping unless you're talking about 
JPA.


Just like object-relational mapping is a general term with many variations and implementations, and supporting the JPA interfaces 
is simply a feature of some of those implementations, portal and portlet are also general terms with many variations and 
implementations, and only some of them support the JSR 168 specification.


Should we then say that portal/portlet software not written in Java should not 
use those terms?

If so, which terms should those unfortunate souls use to describe their 
creations?


OFBiz-portlets and OFBiz-portal ? Not a big deal anyway, just that some people think they will be able to embed some external 
portlets in OFBiz and are dissapointed.


Jacques


-David


On Dec 31, 2009, at 8:48 AM, Jacques Le Roux wrote:


I agree with Ruth, this will (and has already) certainly bring some confusion 
in future.

Jacques

From: "Ruth Hoffman" 

Hi David:
IMO the term "portlet" should only be applied to JSR 168/268 compliant code.

Regards,
Ruth

David E Jones wrote:

MyPortal still needs a lot of work.

It should really be just the shell of the portal and include only a very few 
portlets that are part of the framework.

Higher level components, including applications components, can have their own portlets that appear in MyPortal by having data 
in seed/etc data files, and that data will tell MyPortal about these portlets.


OOTB the MyPortal stuff shouldn't know anything about any portlets (other than a few basic framework ones). At runtime MyPortal 
will look for information about other portlets, but that information should come only from the higher level components where 
the portlets themselves live.


-David


On Dec 31, 2009, at 4:50 AM, Bruno Busco wrote:



That's true, it would be still a dependence.

Anyway, in this case the MyPortal is considered to be dependent from
all other components (because it "mounts" portlets defined by all
other components in the default portalPages).
It should be possible to use the MyPortal component even if one of the
other components is not used.

I think a different logic is needed here.

-Bruno

2009/12/31 David E Jones :


That still represents a dependency on the other component.

Lower level components should not even have anything that represents an 
awareness of a higher level component.

The solution, and the only solution, is to move the data to the higher level 
components. It's that simple.

-David


On Dec 30, 2009, at 5:54 PM, Bruno Busco wrote:



Hi,
the MyPortal component has many seed data that create a dependence
from many other components.
This is done because the seed data create the default MyPortal
portalPages that include several portlets from all other components.

For example:
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  

How can we have a conditional seed data loading that would load only
seed data for the portlets really available in the system?
I mean, could we have something like this:


  
  


or is there any other tecnique to do this?

Many thanks,
Bruno

Re: Conditional seed data loading

[David E Jones]

Bring confusion in the future? That's like saying you shouldn't use the term 
object-relational mapping unless you're talking about JPA.

Just like object-relational mapping is a general term with many variations and 
implementations, and supporting the JPA interfaces is simply a feature of some 
of those implementations, portal and portlet are also general terms with many 
variations and implementations, and only some of them support the JSR 168 
specification.

Should we then say that portal/portlet software not written in Java should not 
use those terms?

If so, which terms should those unfortunate souls use to describe their 
creations?

-David


On Dec 31, 2009, at 8:48 AM, Jacques Le Roux wrote:

> I agree with Ruth, this will (and has already) certainly bring some confusion 
> in future.
> 
> Jacques
> 
> From: "Ruth Hoffman" 
>> Hi David:
>> IMO the term "portlet" should only be applied to JSR 168/268 compliant code.
>> 
>> Regards,
>> Ruth
>> 
>> David E Jones wrote:
>>> MyPortal still needs a lot of work.
>>> 
>>> It should really be just the shell of the portal and include only a very 
>>> few portlets that are part of the framework.
>>> 
>>> Higher level components, including applications components, can have their 
>>> own portlets that appear in MyPortal by having data in seed/etc data files, 
>>> and that data will tell MyPortal about these portlets.
>>> 
>>> OOTB the MyPortal stuff shouldn't know anything about any portlets (other 
>>> than a few basic framework ones). At runtime MyPortal will look for 
>>> information about other portlets, but that information should come only 
>>> from the higher level components where the portlets themselves live.
>>> 
>>> -David
>>> 
>>> 
>>> On Dec 31, 2009, at 4:50 AM, Bruno Busco wrote:
>>> 
>>> 
 That's true, it would be still a dependence.
 
 Anyway, in this case the MyPortal is considered to be dependent from
 all other components (because it "mounts" portlets defined by all
 other components in the default portalPages).
 It should be possible to use the MyPortal component even if one of the
 other components is not used.
 
 I think a different logic is needed here.
 
 -Bruno
 
 2009/12/31 David E Jones :
 
> That still represents a dependency on the other component.
> 
> Lower level components should not even have anything that represents an 
> awareness of a higher level component.
> 
> The solution, and the only solution, is to move the data to the higher 
> level components. It's that simple.
> 
> -David
> 
> 
> On Dec 30, 2009, at 5:54 PM, Bruno Busco wrote:
> 
> 
>> Hi,
>> the MyPortal component has many seed data that create a dependence
>> from many other components.
>> This is done because the seed data create the default MyPortal
>> portalPages that include several portlets from all other components.
>> 
>> For example:
>>   > portalPortletId="SystemInfoNotes" portletSeqId="1"
>> columnSeqId="1" sequenceNum="0"/>
>>   > portalPortletId="SystemInfoStatus" portletSeqId="1"
>> columnSeqId="1" sequenceNum="1"/>
>>   > portalPortletId="Calendar" portletSeqId="1" columnSeqId="1"
>> sequenceNum="2"/>
>>   > portalPortletId="INCOM_CUST_REQUESTS" portletSeqId="1"
>> columnSeqId="1" sequenceNum="0"/>
>>   > portalPortletId="MyCommunications" portletSeqId="1"
>> columnSeqId="1" sequenceNum="1"/>
>>   > portalPortletId="party" portletSeqId="1" columnSeqId="1"
>> sequenceNum="0"/>
>>   > portalPortletId="partyRelContacts" portletSeqId="1"
>> columnSeqId="1" sequenceNum="1"/>
>>   > portalPortletId="partyRelAccounts" portletSeqId="1"
>> columnSeqId="1" sequenceNum="2"/>
>>   > portalPortletId="contact" portletSeqId="1" columnSeqId="1"
>> sequenceNum="3"/>
>>   > portalPortletId="LoyaltyPoints" portletSeqId="1"
>> columnSeqId="1" sequenceNum="4"/>
>>   > portalPortletId="PaymentMethods" portletSeqId="1"
>> columnSeqId="1" sequenceNum="5"/>
>>   > portalPortletId="AvsSettings" portletSeqId="1" columnSeqId="1"
>> sequenceNum="6"/>
>>   > portalPortletId="UserLogin" portletSeqId="1" columnSeqId="2"
>> sequenceNum="1"/>
>>   > portalPortletId="Attributes" portletSeqId="1" columnSeqId="2"
>> sequenceNum="2"/>
>>   > portalPortletId="Visits" portletSeqId="1" columnSeqId="2"
>> sequenceNum="3"/>
>>   > portalPortletId="Content" portletSeqId="1" columnSeqId="2"
>> sequenceNum="4"/>
>>   > portalPortletId="ShipperAccount" portletSeqId="1"
>> columnSeqId="2" sequenceNum="5"/>
>>   > portalPortletId="Notes" portletSeqId="1" columnSeqId="2"
>> sequenceNum="6"/>
>>   >

Re: Conditional seed data loading

[David E Jones]

The terms "portal" and "portlet" existed, and were used in a software user 
interface context, a LONG time before JSR 168 was a twinkle in the eye of the 
fans of ineffective design and standardization for marketing purposes that 
created the spec.

I have no intention of granting them ownership of these words. I don't even 
like their definitions of them!

So, thank you very much, I'll continue using them by their more traditional and 
general definitions and not the limited, and of limited use, definitions 
related to JSR 168.

On the practical side: if we did abandon the term "portlet" we should also 
abandon the term "portal" since they really always go together in the context 
of software user interfaces, and if we abandon those terms we have a lot of 
searching and replacing to do in OFBiz, aside from the small issue of coming up 
with other terms to use for these concepts.

-David


On Dec 31, 2009, at 7:32 AM, Ruth Hoffman wrote:

> Hi David:
> IMO the term "portlet" should only be applied to JSR 168/268 compliant code.
> 
> Regards,
> Ruth
> 
> David E Jones wrote:
>> MyPortal still needs a lot of work.
>> 
>> It should really be just the shell of the portal and include only a very few 
>> portlets that are part of the framework.
>> 
>> Higher level components, including applications components, can have their 
>> own portlets that appear in MyPortal by having data in seed/etc data files, 
>> and that data will tell MyPortal about these portlets.
>> 
>> OOTB the MyPortal stuff shouldn't know anything about any portlets (other 
>> than a few basic framework ones). At runtime MyPortal will look for 
>> information about other portlets, but that information should come only from 
>> the higher level components where the portlets themselves live.
>> 
>> -David
>> 
>> 
>> On Dec 31, 2009, at 4:50 AM, Bruno Busco wrote:
>> 
>>  
>>> That's true, it would be still a dependence.
>>> 
>>> Anyway, in this case the MyPortal is considered to be dependent from
>>> all other components (because it "mounts" portlets defined by all
>>> other components in the default portalPages).
>>> It should be possible to use the MyPortal component even if one of the
>>> other components is not used.
>>> 
>>> I think a different logic is needed here.
>>> 
>>> -Bruno
>>> 
>>> 2009/12/31 David E Jones :
>>>
 That still represents a dependency on the other component.
 
 Lower level components should not even have anything that represents an 
 awareness of a higher level component.
 
 The solution, and the only solution, is to move the data to the higher 
 level components. It's that simple.
 
 -David
 
 
 On Dec 30, 2009, at 5:54 PM, Bruno Busco wrote:
 
  
> Hi,
> the MyPortal component has many seed data that create a dependence
> from many other components.
> This is done because the seed data create the default MyPortal
> portalPages that include several portlets from all other components.
> 
> For example:
>    portalPortletId="SystemInfoNotes" portletSeqId="1"
> columnSeqId="1" sequenceNum="0"/>
>    portalPortletId="SystemInfoStatus" portletSeqId="1"
> columnSeqId="1" sequenceNum="1"/>
>    portalPortletId="Calendar" portletSeqId="1" columnSeqId="1"
> sequenceNum="2"/>
>    portalPortletId="INCOM_CUST_REQUESTS" portletSeqId="1"
> columnSeqId="1" sequenceNum="0"/>
>    portalPortletId="MyCommunications" portletSeqId="1"
> columnSeqId="1" sequenceNum="1"/>
>    portalPortletId="party" portletSeqId="1" columnSeqId="1"
> sequenceNum="0"/>
>    portalPortletId="partyRelContacts" portletSeqId="1"
> columnSeqId="1" sequenceNum="1"/>
>    portalPortletId="partyRelAccounts" portletSeqId="1"
> columnSeqId="1" sequenceNum="2"/>
>    portalPortletId="contact" portletSeqId="1" columnSeqId="1"
> sequenceNum="3"/>
>    portalPortletId="LoyaltyPoints" portletSeqId="1"
> columnSeqId="1" sequenceNum="4"/>
>    portalPortletId="PaymentMethods" portletSeqId="1"
> columnSeqId="1" sequenceNum="5"/>
>    portalPortletId="AvsSettings" portletSeqId="1" columnSeqId="1"
> sequenceNum="6"/>
>    portalPortletId="UserLogin" portletSeqId="1" columnSeqId="2"
> sequenceNum="1"/>
>    portalPortletId="Attributes" portletSeqId="1" columnSeqId="2"
> sequenceNum="2"/>
>    portalPortletId="Visits" portletSeqId="1" columnSeqId="2"
> sequenceNum="3"/>
>    portalPortletId="Content" portletSeqId="1" columnSeqId="2"
> sequenceNum="4"/>
>    portalPortletId="ShipperAccount" portletSeqId="1"
> columnSeqId="2" sequenceNum="5"/>
>    portalPortletId="Notes" portletSeqId="1" columnSeqId="2"
> sequenceNum="6"/>
>   >>>

Re: Conditional seed data loading

[Jacques Le Roux]

I agree with Ruth, this will (and has already) certainly bring some confusion 
in future.

Jacques

From: "Ruth Hoffman" 

Hi David:
IMO the term "portlet" should only be applied to JSR 168/268 compliant code.

Regards,
Ruth

David E Jones wrote:

MyPortal still needs a lot of work.

It should really be just the shell of the portal and include only a very few 
portlets that are part of the framework.

Higher level components, including applications components, can have their own portlets that appear in MyPortal by having data in 
seed/etc data files, and that data will tell MyPortal about these portlets.


OOTB the MyPortal stuff shouldn't know anything about any portlets (other than a few basic framework ones). At runtime MyPortal 
will look for information about other portlets, but that information should come only from the higher level components where the 
portlets themselves live.


-David


On Dec 31, 2009, at 4:50 AM, Bruno Busco wrote:



That's true, it would be still a dependence.

Anyway, in this case the MyPortal is considered to be dependent from
all other components (because it "mounts" portlets defined by all
other components in the default portalPages).
It should be possible to use the MyPortal component even if one of the
other components is not used.

I think a different logic is needed here.

-Bruno

2009/12/31 David E Jones :


That still represents a dependency on the other component.

Lower level components should not even have anything that represents an 
awareness of a higher level component.

The solution, and the only solution, is to move the data to the higher level 
components. It's that simple.

-David


On Dec 30, 2009, at 5:54 PM, Bruno Busco wrote:



Hi,
the MyPortal component has many seed data that create a dependence
from many other components.
This is done because the seed data create the default MyPortal
portalPages that include several portlets from all other components.

For example:
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   

How can we have a conditional seed data loading that would load only
seed data for the portlets really available in the system?
I mean, could we have something like this:


   
   


or is there any other tecnique to do this?

Many thanks,
Bruno

Re: Conditional seed data loading

[Ruth Hoffman]

Hi David:
IMO the term "portlet" should only be applied to JSR 168/268 compliant 
code.


Regards,
Ruth

David E Jones wrote:

MyPortal still needs a lot of work.

It should really be just the shell of the portal and include only a very few 
portlets that are part of the framework.

Higher level components, including applications components, can have their own 
portlets that appear in MyPortal by having data in seed/etc data files, and 
that data will tell MyPortal about these portlets.

OOTB the MyPortal stuff shouldn't know anything about any portlets (other than 
a few basic framework ones). At runtime MyPortal will look for information 
about other portlets, but that information should come only from the higher 
level components where the portlets themselves live.

-David


On Dec 31, 2009, at 4:50 AM, Bruno Busco wrote:

  

That's true, it would be still a dependence.

Anyway, in this case the MyPortal is considered to be dependent from
all other components (because it "mounts" portlets defined by all
other components in the default portalPages).
It should be possible to use the MyPortal component even if one of the
other components is not used.

I think a different logic is needed here.

-Bruno

2009/12/31 David E Jones :


That still represents a dependency on the other component.

Lower level components should not even have anything that represents an 
awareness of a higher level component.

The solution, and the only solution, is to move the data to the higher level 
components. It's that simple.

-David


On Dec 30, 2009, at 5:54 PM, Bruno Busco wrote:

  

Hi,
the MyPortal component has many seed data that create a dependence
from many other components.
This is done because the seed data create the default MyPortal
portalPages that include several portlets from all other components.

For example:
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   

How can we have a conditional seed data loading that would load only
seed data for the portlets really available in the system?
I mean, could we have something like this:


   
   


or is there any other tecnique to do this?

Many thanks,
Bruno

  



  

Re: Conditional seed data loading

[Bruno Busco]

David,
I totally agree with you and will work to get this.

So, the portalPages that are actually defined in MyPortal should be
defined in a different seed or a different component that is at the
highest level.
A solution could also be to define those portlaPages in the setup
(even if I do not really know very much about the setup).
WDYT?

-Bruno

2009/12/31 David E Jones :
>
> MyPortal still needs a lot of work.
>
> It should really be just the shell of the portal and include only a very few 
> portlets that are part of the framework.
>
> Higher level components, including applications components, can have their 
> own portlets that appear in MyPortal by having data in seed/etc data files, 
> and that data will tell MyPortal about these portlets.
>
> OOTB the MyPortal stuff shouldn't know anything about any portlets (other 
> than a few basic framework ones). At runtime MyPortal will look for 
> information about other portlets, but that information should come only from 
> the higher level components where the portlets themselves live.
>
> -David
>
>
> On Dec 31, 2009, at 4:50 AM, Bruno Busco wrote:
>
>> That's true, it would be still a dependence.
>>
>> Anyway, in this case the MyPortal is considered to be dependent from
>> all other components (because it "mounts" portlets defined by all
>> other components in the default portalPages).
>> It should be possible to use the MyPortal component even if one of the
>> other components is not used.
>>
>> I think a different logic is needed here.
>>
>> -Bruno
>>
>> 2009/12/31 David E Jones :
>>>
>>> That still represents a dependency on the other component.
>>>
>>> Lower level components should not even have anything that represents an 
>>> awareness of a higher level component.
>>>
>>> The solution, and the only solution, is to move the data to the higher 
>>> level components. It's that simple.
>>>
>>> -David
>>>
>>>
>>> On Dec 30, 2009, at 5:54 PM, Bruno Busco wrote:
>>>
 Hi,
 the MyPortal component has many seed data that create a dependence
 from many other components.
 This is done because the seed data create the default MyPortal
 portalPages that include several portlets from all other components.

 For example:
    >>> portalPortletId="SystemInfoNotes" portletSeqId="1"
 columnSeqId="1" sequenceNum="0"/>
    >>> portalPortletId="SystemInfoStatus" portletSeqId="1"
 columnSeqId="1" sequenceNum="1"/>
    >>> portalPortletId="Calendar" portletSeqId="1" columnSeqId="1"
 sequenceNum="2"/>
    >>> portalPortletId="INCOM_CUST_REQUESTS" portletSeqId="1"
 columnSeqId="1" sequenceNum="0"/>
    >>> portalPortletId="MyCommunications" portletSeqId="1"
 columnSeqId="1" sequenceNum="1"/>
    >>> portalPortletId="party" portletSeqId="1" columnSeqId="1"
 sequenceNum="0"/>
    >>> portalPortletId="partyRelContacts" portletSeqId="1"
 columnSeqId="1" sequenceNum="1"/>
    >>> portalPortletId="partyRelAccounts" portletSeqId="1"
 columnSeqId="1" sequenceNum="2"/>
    >>> portalPortletId="contact" portletSeqId="1" columnSeqId="1"
 sequenceNum="3"/>
    >>> portalPortletId="LoyaltyPoints" portletSeqId="1"
 columnSeqId="1" sequenceNum="4"/>
    >>> portalPortletId="PaymentMethods" portletSeqId="1"
 columnSeqId="1" sequenceNum="5"/>
    >>> portalPortletId="AvsSettings" portletSeqId="1" columnSeqId="1"
 sequenceNum="6"/>
    >>> portalPortletId="UserLogin" portletSeqId="1" columnSeqId="2"
 sequenceNum="1"/>
    >>> portalPortletId="Attributes" portletSeqId="1" columnSeqId="2"
 sequenceNum="2"/>
    >>> portalPortletId="Visits" portletSeqId="1" columnSeqId="2"
 sequenceNum="3"/>
    >>> portalPortletId="Content" portletSeqId="1" columnSeqId="2"
 sequenceNum="4"/>
    >>> portalPortletId="ShipperAccount" portletSeqId="1"
 columnSeqId="2" sequenceNum="5"/>
    >>> portalPortletId="Notes" portletSeqId="1" columnSeqId="2"
 sequenceNum="6"/>
    >>> portalPortletId="MYTASKSPARTY" portletSeqId="1"
 columnSeqId="2" sequenceNum="7"/>
    >>> portalPortletId="MyCommunications" portletSeqId="1"
 columnSeqId="1" sequenceNum="0"/>
    >>> portalPortletId="MyCommunications" portletSeqId="1"
 attrName="communicationPartyId" attrValue="Company"/>
    >>> portalPortletId="mytimesheet" portletSeqId="1" columnSeqId="1"
 sequenceNum="0"/>
    >>> portalPortletId="mytasks" portletSeqId="1" columnSeqId="1"
 sequenceNum="0"/>

 How can we have a conditional seed data loading that would load only
 seed data for the portlets really available in the system?
 I mean, could we have something like this:

 
    >>> portalPortletId="mytimesheet" portletSeqId="1" columnSeqId="1"
 sequenc

Re: Conditional seed data loading

[David E Jones]

MyPortal still needs a lot of work.

It should really be just the shell of the portal and include only a very few 
portlets that are part of the framework.

Higher level components, including applications components, can have their own 
portlets that appear in MyPortal by having data in seed/etc data files, and 
that data will tell MyPortal about these portlets.

OOTB the MyPortal stuff shouldn't know anything about any portlets (other than 
a few basic framework ones). At runtime MyPortal will look for information 
about other portlets, but that information should come only from the higher 
level components where the portlets themselves live.

-David


On Dec 31, 2009, at 4:50 AM, Bruno Busco wrote:

> That's true, it would be still a dependence.
> 
> Anyway, in this case the MyPortal is considered to be dependent from
> all other components (because it "mounts" portlets defined by all
> other components in the default portalPages).
> It should be possible to use the MyPortal component even if one of the
> other components is not used.
> 
> I think a different logic is needed here.
> 
> -Bruno
> 
> 2009/12/31 David E Jones :
>> 
>> That still represents a dependency on the other component.
>> 
>> Lower level components should not even have anything that represents an 
>> awareness of a higher level component.
>> 
>> The solution, and the only solution, is to move the data to the higher level 
>> components. It's that simple.
>> 
>> -David
>> 
>> 
>> On Dec 30, 2009, at 5:54 PM, Bruno Busco wrote:
>> 
>>> Hi,
>>> the MyPortal component has many seed data that create a dependence
>>> from many other components.
>>> This is done because the seed data create the default MyPortal
>>> portalPages that include several portlets from all other components.
>>> 
>>> For example:
>>>>> portalPortletId="SystemInfoNotes" portletSeqId="1"
>>> columnSeqId="1" sequenceNum="0"/>
>>>>> portalPortletId="SystemInfoStatus" portletSeqId="1"
>>> columnSeqId="1" sequenceNum="1"/>
>>>>> portalPortletId="Calendar" portletSeqId="1" columnSeqId="1"
>>> sequenceNum="2"/>
>>>>> portalPortletId="INCOM_CUST_REQUESTS" portletSeqId="1"
>>> columnSeqId="1" sequenceNum="0"/>
>>>>> portalPortletId="MyCommunications" portletSeqId="1"
>>> columnSeqId="1" sequenceNum="1"/>
>>>>> portalPortletId="party" portletSeqId="1" columnSeqId="1"
>>> sequenceNum="0"/>
>>>>> portalPortletId="partyRelContacts" portletSeqId="1"
>>> columnSeqId="1" sequenceNum="1"/>
>>>>> portalPortletId="partyRelAccounts" portletSeqId="1"
>>> columnSeqId="1" sequenceNum="2"/>
>>>>> portalPortletId="contact" portletSeqId="1" columnSeqId="1"
>>> sequenceNum="3"/>
>>>>> portalPortletId="LoyaltyPoints" portletSeqId="1"
>>> columnSeqId="1" sequenceNum="4"/>
>>>>> portalPortletId="PaymentMethods" portletSeqId="1"
>>> columnSeqId="1" sequenceNum="5"/>
>>>>> portalPortletId="AvsSettings" portletSeqId="1" columnSeqId="1"
>>> sequenceNum="6"/>
>>>>> portalPortletId="UserLogin" portletSeqId="1" columnSeqId="2"
>>> sequenceNum="1"/>
>>>>> portalPortletId="Attributes" portletSeqId="1" columnSeqId="2"
>>> sequenceNum="2"/>
>>>>> portalPortletId="Visits" portletSeqId="1" columnSeqId="2"
>>> sequenceNum="3"/>
>>>>> portalPortletId="Content" portletSeqId="1" columnSeqId="2"
>>> sequenceNum="4"/>
>>>>> portalPortletId="ShipperAccount" portletSeqId="1"
>>> columnSeqId="2" sequenceNum="5"/>
>>>>> portalPortletId="Notes" portletSeqId="1" columnSeqId="2"
>>> sequenceNum="6"/>
>>>>> portalPortletId="MYTASKSPARTY" portletSeqId="1"
>>> columnSeqId="2" sequenceNum="7"/>
>>>>> portalPortletId="MyCommunications" portletSeqId="1"
>>> columnSeqId="1" sequenceNum="0"/>
>>>>> portalPortletId="MyCommunications" portletSeqId="1"
>>> attrName="communicationPartyId" attrValue="Company"/>
>>>>> portalPortletId="mytimesheet" portletSeqId="1" columnSeqId="1"
>>> sequenceNum="0"/>
>>>>> portalPortletId="mytasks" portletSeqId="1" columnSeqId="1"
>>> sequenceNum="0"/>
>>> 
>>> How can we have a conditional seed data loading that would load only
>>> seed data for the portlets really available in the system?
>>> I mean, could we have something like this:
>>> 
>>> 
>>>>> portalPortletId="mytimesheet" portletSeqId="1" columnSeqId="1"
>>> sequenceNum="0"/>
>>>>> portalPortletId="mytasks" portletSeqId="1" columnSeqId="1"
>>> sequenceNum="0"/>
>>> 
>>> 
>>> or is there any other tecnique to do this?
>>> 
>>> Many thanks,
>>> Bruno
>> 
>> 

Re: Conditional seed data loading

[Bruno Busco]

That's true, it would be still a dependence.

Anyway, in this case the MyPortal is considered to be dependent from
all other components (because it "mounts" portlets defined by all
other components in the default portalPages).
It should be possible to use the MyPortal component even if one of the
other components is not used.

I think a different logic is needed here.

-Bruno

2009/12/31 David E Jones :
>
> That still represents a dependency on the other component.
>
> Lower level components should not even have anything that represents an 
> awareness of a higher level component.
>
> The solution, and the only solution, is to move the data to the higher level 
> components. It's that simple.
>
> -David
>
>
> On Dec 30, 2009, at 5:54 PM, Bruno Busco wrote:
>
>> Hi,
>> the MyPortal component has many seed data that create a dependence
>> from many other components.
>> This is done because the seed data create the default MyPortal
>> portalPages that include several portlets from all other components.
>>
>> For example:
>>    > portalPortletId="SystemInfoNotes" portletSeqId="1"
>> columnSeqId="1" sequenceNum="0"/>
>>    > portalPortletId="SystemInfoStatus" portletSeqId="1"
>> columnSeqId="1" sequenceNum="1"/>
>>    > portalPortletId="Calendar" portletSeqId="1" columnSeqId="1"
>> sequenceNum="2"/>
>>    > portalPortletId="INCOM_CUST_REQUESTS" portletSeqId="1"
>> columnSeqId="1" sequenceNum="0"/>
>>    > portalPortletId="MyCommunications" portletSeqId="1"
>> columnSeqId="1" sequenceNum="1"/>
>>    > portalPortletId="party" portletSeqId="1" columnSeqId="1"
>> sequenceNum="0"/>
>>    > portalPortletId="partyRelContacts" portletSeqId="1"
>> columnSeqId="1" sequenceNum="1"/>
>>    > portalPortletId="partyRelAccounts" portletSeqId="1"
>> columnSeqId="1" sequenceNum="2"/>
>>    > portalPortletId="contact" portletSeqId="1" columnSeqId="1"
>> sequenceNum="3"/>
>>    > portalPortletId="LoyaltyPoints" portletSeqId="1"
>> columnSeqId="1" sequenceNum="4"/>
>>    > portalPortletId="PaymentMethods" portletSeqId="1"
>> columnSeqId="1" sequenceNum="5"/>
>>    > portalPortletId="AvsSettings" portletSeqId="1" columnSeqId="1"
>> sequenceNum="6"/>
>>    > portalPortletId="UserLogin" portletSeqId="1" columnSeqId="2"
>> sequenceNum="1"/>
>>    > portalPortletId="Attributes" portletSeqId="1" columnSeqId="2"
>> sequenceNum="2"/>
>>    > portalPortletId="Visits" portletSeqId="1" columnSeqId="2"
>> sequenceNum="3"/>
>>    > portalPortletId="Content" portletSeqId="1" columnSeqId="2"
>> sequenceNum="4"/>
>>    > portalPortletId="ShipperAccount" portletSeqId="1"
>> columnSeqId="2" sequenceNum="5"/>
>>    > portalPortletId="Notes" portletSeqId="1" columnSeqId="2"
>> sequenceNum="6"/>
>>    > portalPortletId="MYTASKSPARTY" portletSeqId="1"
>> columnSeqId="2" sequenceNum="7"/>
>>    > portalPortletId="MyCommunications" portletSeqId="1"
>> columnSeqId="1" sequenceNum="0"/>
>>    > portalPortletId="MyCommunications" portletSeqId="1"
>> attrName="communicationPartyId" attrValue="Company"/>
>>    > portalPortletId="mytimesheet" portletSeqId="1" columnSeqId="1"
>> sequenceNum="0"/>
>>    > portalPortletId="mytasks" portletSeqId="1" columnSeqId="1"
>> sequenceNum="0"/>
>>
>> How can we have a conditional seed data loading that would load only
>> seed data for the portlets really available in the system?
>> I mean, could we have something like this:
>>
>> 
>>    > portalPortletId="mytimesheet" portletSeqId="1" columnSeqId="1"
>> sequenceNum="0"/>
>>    > portalPortletId="mytasks" portletSeqId="1" columnSeqId="1"
>> sequenceNum="0"/>
>> 
>>
>> or is there any other tecnique to do this?
>>
>> Many thanks,
>> Bruno
>
>

Re: Conditional seed data loading

[David E Jones]

That still represents a dependency on the other component.

Lower level components should not even have anything that represents an 
awareness of a higher level component.

The solution, and the only solution, is to move the data to the higher level 
components. It's that simple.

-David


On Dec 30, 2009, at 5:54 PM, Bruno Busco wrote:

> Hi,
> the MyPortal component has many seed data that create a dependence
> from many other components.
> This is done because the seed data create the default MyPortal
> portalPages that include several portlets from all other components.
> 
> For example:
> portalPortletId="SystemInfoNotes" portletSeqId="1"
> columnSeqId="1" sequenceNum="0"/>
> portalPortletId="SystemInfoStatus" portletSeqId="1"
> columnSeqId="1" sequenceNum="1"/>
> portalPortletId="Calendar" portletSeqId="1" columnSeqId="1"
> sequenceNum="2"/>
> portalPortletId="INCOM_CUST_REQUESTS" portletSeqId="1"
> columnSeqId="1" sequenceNum="0"/>
> portalPortletId="MyCommunications" portletSeqId="1"
> columnSeqId="1" sequenceNum="1"/>
> portalPortletId="party" portletSeqId="1" columnSeqId="1"
> sequenceNum="0"/>
> portalPortletId="partyRelContacts" portletSeqId="1"
> columnSeqId="1" sequenceNum="1"/>
> portalPortletId="partyRelAccounts" portletSeqId="1"
> columnSeqId="1" sequenceNum="2"/>
> portalPortletId="contact" portletSeqId="1" columnSeqId="1"
> sequenceNum="3"/>
> portalPortletId="LoyaltyPoints" portletSeqId="1"
> columnSeqId="1" sequenceNum="4"/>
> portalPortletId="PaymentMethods" portletSeqId="1"
> columnSeqId="1" sequenceNum="5"/>
> portalPortletId="AvsSettings" portletSeqId="1" columnSeqId="1"
> sequenceNum="6"/>
> portalPortletId="UserLogin" portletSeqId="1" columnSeqId="2"
> sequenceNum="1"/>
> portalPortletId="Attributes" portletSeqId="1" columnSeqId="2"
> sequenceNum="2"/>
> portalPortletId="Visits" portletSeqId="1" columnSeqId="2"
> sequenceNum="3"/>
> portalPortletId="Content" portletSeqId="1" columnSeqId="2"
> sequenceNum="4"/>
> portalPortletId="ShipperAccount" portletSeqId="1"
> columnSeqId="2" sequenceNum="5"/>
> portalPortletId="Notes" portletSeqId="1" columnSeqId="2"
> sequenceNum="6"/>
> portalPortletId="MYTASKSPARTY" portletSeqId="1"
> columnSeqId="2" sequenceNum="7"/>
> portalPortletId="MyCommunications" portletSeqId="1"
> columnSeqId="1" sequenceNum="0"/>
> portalPortletId="MyCommunications" portletSeqId="1"
> attrName="communicationPartyId" attrValue="Company"/>
> portalPortletId="mytimesheet" portletSeqId="1" columnSeqId="1"
> sequenceNum="0"/>
> portalPortletId="mytasks" portletSeqId="1" columnSeqId="1"
> sequenceNum="0"/>
> 
> How can we have a conditional seed data loading that would load only
> seed data for the portlets really available in the system?
> I mean, could we have something like this:
> 
> 
> portalPortletId="mytimesheet" portletSeqId="1" columnSeqId="1"
> sequenceNum="0"/>
> portalPortletId="mytasks" portletSeqId="1" columnSeqId="1"
> sequenceNum="0"/>
> 
> 
> or is there any other tecnique to do this?
> 
> Many thanks,
> Bruno