Discussion: Home application (was: Pluggable preferences/profile screen)

[Bruno Busco]

David,
I found in the ML some citations of the Apache Pluto project that is JSR 168
compliant. May be this is what you are referring to.
It would be really nice to have the MyPage application rolled out using this
kind of tecnology but I am actually too far from having a clear idea of the
efforts required to do it.

However I propose to spend some time discussing and collecting requirement
specifications for an application that I feel missing into OFBiz OOTB and
that, may be, is something near to what MyPage seems trying to be.

I would call the missing application simply "Home".

- The main purpose of the Home application would be to have a "solid" access
point to OFBiz that is always accessible to every user.
- From this application the user should be able to access all applications
he has permission to.
- Should be directly able (without accessing any other application) to
change his profile and user preferences.
- Should be able to create and configure as many "dashboard" pages as he
likes. And on every page should be able to put screenlets elements defined
by all installed applications. These features extends what is actually
implemented in MyPage application and, in my opinion, gives a great value to
the entire OFBiz system. (I would use JIRA as a model)

You already said that this kind of things are well implemented into JRS 168
compliant portals but may be it would be better to start defining common
agreed specifications (we could have a JIRA for this) and then, before
starting working, decide if doing it with external tecnologies (like Pluto
for instance) or improving and giving more generality to the actual MyPage
application using the OFBiz screenlets.

I hope to hear from you all something about that.

Many thanks,
-Bruno


2008/8/15 David E. Jones <[hidden email]>

>
> While it wouldn't make sense for most of OFBiz, for the MyPage stuff a
> portal framework would be really valuable. Many of the things you
> describe here are basically what a portal framework does (ie the JSR 168
> type of stuff). Other things would have to be added on to make things
> happen automatically based on other stuff in OFBiz, ie some integration
> stuff, but it might be a good idea. There is even a decent little portal
> that is an Apache project...
>
> -David
>
>
> On Fri, 2008-08-15 at 12:41 +0200, Bruno Busco wrote:
> > Thinking more about this may be the same concept of pluggability could be
> > used in the MyPage component.
> > Every application could register in some way several own screens that
> will
> > then all available to the user in the MyPage.
> > Using the enable/disable checkboxes the user coud configure its "MyPage"
> > picking up things from applications in an application-driven way.
> > -Bruno
> >
> > 2008/8/15 Bruno Busco <[hidden email]>
> >
> > > Hi all,
> > > while writing the compact header we had to define which links to have
> > > available to the user in the compact header itself.
> > > The "profile" link would seem to be a good candidate (quite standard)
> but,
> > > since the viewprofile page is now external to the framework, this
> offers the
> > > occasion to think about the viewprofile and the preference page itself.
> > >
> > > I have the idea that the profile/preference page could be pluggable.
> > > It is quite common that new components have some new preferences to
> offer
> > > to the user.
> > > Having the profile/preference page pluggable we could let other
> > > applications to add their specific elements to the standard preference
> pages
> > > content.
> > >
> > > The standard "preference" page, defined in the framework, should let
> the
> > > user to change his name, e-mail, password, locale language, timezone,
> > > VisualTheme etc.
> > > Additional applications-defined preferences will be added (in a way to
> be
> > > defined) and shown to the user in the same page of the standard
> preferences
> > > or the like.
> > > A possible way to plug application-specific preferences could be that
> > > application "registers" its own preferences pages adding the path to
> locally
> > > defined preferences screen into a globally framework-defined array.
> > > This array could be used by the framework preference page to populate a
> > > TabBarMenu so that all applications preferences will be available at
> one
> > > place.
> > >
> > > What do you think about?
> > > Thanks,
> > > -Bruno
> > >
>
>

[Adrian Crum-2]

I created a Home application for my employer. The Home page has a link to create a new OFBiz user account so that new employees can create their own account.

A new user is given some basic permissions. Their Home page allows them to set preferences, update their profile, and send and receive communications. All new users also have access to the calendar application and the company forums.

I hoped the MyPage component could be used for that, but it went off into another direction. I asked Hans if we could keep MyPage generic enough for new users to use, but I wasn't successful.

I could contribute some of my Home page work to the project (in fact, the calendar work I'm doing right now is part of that) but we need a place for it to land.

-Adrian

--- On Sun, 10/5/08, Bruno Busco <[hidden email]> wrote:

> From: Bruno Busco <[hidden email]>
> Subject: Discussion: Home application (was: Pluggable preferences/profile screen)
> To: [hidden email]
> Date: Sunday, October 5, 2008, 2:05 AM
> David,
> I found in the ML some citations of the Apache Pluto
> project that is JSR 168
> compliant. May be this is what you are referring to.
> It would be really nice to have the MyPage application
> rolled out using this
> kind of tecnology but I am actually too far from having a
> clear idea of the
> efforts required to do it.
>
> However I propose to spend some time discussing and
> collecting requirement
> specifications for an application that I feel missing into
> OFBiz OOTB and
> that, may be, is something near to what MyPage seems trying
> to be.
>
> I would call the missing application simply
> "Home".
>
> - The main purpose of the Home application would be to have
> a "solid" access
> point to OFBiz that is always accessible to every user.
> - From this application the user should be able to access
> all applications
> he has permission to.
> - Should be directly able (without accessing any other
> application) to
> change his profile and user preferences.
> - Should be able to create and configure as many
> "dashboard" pages as he
> likes. And on every page should be able to put screenlets
> elements defined
> by all installed applications. These features extends what
> is actually
> implemented in MyPage application and, in my opinion, gives
> a great value to
> the entire OFBiz system. (I would use JIRA as a model)
>
> You already said that this kind of things are well
> implemented into JRS 168
> compliant portals but may be it would be better to start
> defining common
> agreed specifications (we could have a JIRA for this) and
> then, before
> starting working, decide if doing it with external
> tecnologies (like Pluto
> for instance) or improving and giving more generality to
> the actual MyPage
> application using the OFBiz screenlets.
>
> I hope to hear from you all something about that.
>
> Many thanks,
> -Bruno
>
>
> 2008/8/15 David E. Jones <[hidden email]>
>
> >
> > While it wouldn't make sense for most of OFBiz,
> for the MyPage stuff a
> > portal framework would be really valuable. Many of the
> things you
> > describe here are basically what a portal framework
> does (ie the JSR 168
> > type of stuff). Other things would have to be added on
> to make things
> > happen automatically based on other stuff in OFBiz, ie
> some integration
> > stuff, but it might be a good idea. There is even a
> decent little portal
> > that is an Apache project...
> >
> > -David
> >
> >
> > On Fri, 2008-08-15 at 12:41 +0200, Bruno Busco wrote:
> > > Thinking more about this may be the same concept
> of pluggability could be
> > > used in the MyPage component.
> > > Every application could register in some way
> several own screens that
> > will
> > > then all available to the user in the MyPage.
> > > Using the enable/disable checkboxes the user coud
> configure its "MyPage"
> > > picking up things from applications in an
> application-driven way.
> > > -Bruno
> > >
> > > 2008/8/15 Bruno Busco
> <[hidden email]>
> > >
> > > > Hi all,
> > > > while writing the compact header we had to
> define which links to have
> > > > available to the user in the compact header
> itself.
> > > > The "profile" link would seem to
> be a good candidate (quite standard)
> > but,
> > > > since the viewprofile page is now external
> to the framework, this
> > offers the
> > > > occasion to think about the viewprofile and
> the preference page itself.
> > > >
> > > > I have the idea that the profile/preference
> page could be pluggable.
> > > > It is quite common that new components have
> some new preferences to
> > offer
> > > > to the user.
> > > > Having the profile/preference page pluggable
> we could let other
> > > > applications to add their specific elements
> to the standard preference
> > pages
> > > > content.
> > > >
> > > > The standard "preference" page,
> defined in the framework, should let
> > the
> > > > user to change his name, e-mail, password,
> locale language, timezone,
> > > > VisualTheme etc.
> > > > Additional applications-defined preferences
> will be added (in a way to
> > be
> > > > defined) and shown to the user in the same
> page of the standard
> > preferences
> > > > or the like.
> > > > A possible way to plug application-specific
> preferences could be that
> > > > application "registers" its own
> preferences pages adding the path to
> > locally
> > > > defined preferences screen into a globally
> framework-defined array.
> > > > This array could be used by the framework
> preference page to populate a
> > > > TabBarMenu so that all applications
> preferences will be available at
> > one
> > > > place.
> > > >
> > > > What do you think about?
> > > > Thanks,
> > > > -Bruno
> > > >
> >
> >

     

[Bruno Busco]

Adrian,
what you say sounds really great to me.
It would be nice to have your contribution available to let me and others
contribute and go further.

When you say "a place for it to land" are you thinking to something like a
sandbox folder into SVN may be?
I think this would be the best and not proceeding with patch updating in a
JIRA issue because it could take some time to get the new component stable.

I could also start a Confluence page to write down some ideas I have for the
home application in order to share, discuss, agree and implement them all.
Just give me an OK and I will start the Confluence page.

Thank you,
-Bruno

2008/10/5 Adrian Crum <[hidden email]>

> I created a Home application for my employer. The Home page has a link to
> create a new OFBiz user account so that new employees can create their own
> account.
>
> A new user is given some basic permissions. Their Home page allows them to
> set preferences, update their profile, and send and receive communications.
> All new users also have access to the calendar application and the company
> forums.
>
> I hoped the MyPage component could be used for that, but it went off into
> another direction. I asked Hans if we could keep MyPage generic enough for
> new users to use, but I wasn't successful.
>
> I could contribute some of my Home page work to the project (in fact, the
> calendar work I'm doing right now is part of that) but we need a place for
> it to land.
>
> -Adrian
>
> --- On Sun, 10/5/08, Bruno Busco <[hidden email]> wrote:
>
> > From: Bruno Busco <[hidden email]>
> > Subject: Discussion: Home application (was: Pluggable preferences/profile
> screen)
> > To: [hidden email]
> > Date: Sunday, October 5, 2008, 2:05 AM
> > David,
> > I found in the ML some citations of the Apache Pluto
> > project that is JSR 168
> > compliant. May be this is what you are referring to.
> > It would be really nice to have the MyPage application
> > rolled out using this
> > kind of tecnology but I am actually too far from having a
> > clear idea of the
> > efforts required to do it.
> >
> > However I propose to spend some time discussing and
> > collecting requirement
> > specifications for an application that I feel missing into
> > OFBiz OOTB and
> > that, may be, is something near to what MyPage seems trying
> > to be.
> >
> > I would call the missing application simply
> > "Home".
> >
> > - The main purpose of the Home application would be to have
> > a "solid" access
> > point to OFBiz that is always accessible to every user.
> > - From this application the user should be able to access
> > all applications
> > he has permission to.
> > - Should be directly able (without accessing any other
> > application) to
> > change his profile and user preferences.
> > - Should be able to create and configure as many
> > "dashboard" pages as he
> > likes. And on every page should be able to put screenlets
> > elements defined
> > by all installed applications. These features extends what
> > is actually
> > implemented in MyPage application and, in my opinion, gives
> > a great value to
> > the entire OFBiz system. (I would use JIRA as a model)
> >
> > You already said that this kind of things are well
> > implemented into JRS 168
> > compliant portals but may be it would be better to start
> > defining common
> > agreed specifications (we could have a JIRA for this) and
> > then, before
> > starting working, decide if doing it with external
> > tecnologies (like Pluto
> > for instance) or improving and giving more generality to
> > the actual MyPage
> > application using the OFBiz screenlets.
> >
> > I hope to hear from you all something about that.
> >
> > Many thanks,
> > -Bruno
> >
> >
> > 2008/8/15 David E. Jones <[hidden email]>
> >
> > >
> > > While it wouldn't make sense for most of OFBiz,
> > for the MyPage stuff a
> > > portal framework would be really valuable. Many of the
> > things you
> > > describe here are basically what a portal framework
> > does (ie the JSR 168
> > > type of stuff). Other things would have to be added on
> > to make things
> > > happen automatically based on other stuff in OFBiz, ie
> > some integration
> > > stuff, but it might be a good idea. There is even a
> > decent little portal
> > > that is an Apache project...
> > >
> > > -David
> > >
> > >
> > > On Fri, 2008-08-15 at 12:41 +0200, Bruno Busco wrote:
> > > > Thinking more about this may be the same concept
> > of pluggability could be
> > > > used in the MyPage component.
> > > > Every application could register in some way
> > several own screens that
> > > will
> > > > then all available to the user in the MyPage.
> > > > Using the enable/disable checkboxes the user coud
> > configure its "MyPage"
> > > > picking up things from applications in an
> > application-driven way.
> > > > -Bruno
> > > >
> > > > 2008/8/15 Bruno Busco
> > <[hidden email]>
> > > >
> > > > > Hi all,
> > > > > while writing the compact header we had to
> > define which links to have
> > > > > available to the user in the compact header
> > itself.
> > > > > The "profile" link would seem to
> > be a good candidate (quite standard)
> > > but,
> > > > > since the viewprofile page is now external
> > to the framework, this
> > > offers the
> > > > > occasion to think about the viewprofile and
> > the preference page itself.
> > > > >
> > > > > I have the idea that the profile/preference
> > page could be pluggable.
> > > > > It is quite common that new components have
> > some new preferences to
> > > offer
> > > > > to the user.
> > > > > Having the profile/preference page pluggable
> > we could let other
> > > > > applications to add their specific elements
> > to the standard preference
> > > pages
> > > > > content.
> > > > >
> > > > > The standard "preference" page,
> > defined in the framework, should let
> > > the
> > > > > user to change his name, e-mail, password,
> > locale language, timezone,
> > > > > VisualTheme etc.
> > > > > Additional applications-defined preferences
> > will be added (in a way to
> > > be
> > > > > defined) and shown to the user in the same
> > page of the standard
> > > preferences
> > > > > or the like.
> > > > > A possible way to plug application-specific
> > preferences could be that
> > > > > application "registers" its own
> > preferences pages adding the path to
> > > locally
> > > > > defined preferences screen into a globally
> > framework-defined array.
> > > > > This array could be used by the framework
> > preference page to populate a
> > > > > TabBarMenu so that all applications
> > preferences will be available at
> > > one
> > > > > place.
> > > > >
> > > > > What do you think about?
> > > > > Thanks,
> > > > > -Bruno
> > > > >
> > >
> > >
>
>
>
>

[Adrian Crum-2]

What I meant was a place in the trunk for it to land - a component.

I'm working with Hans off-list on how we can get the MyPage component to accommodate our needs.

-Adrian


--- On Sun, 10/5/08, Bruno Busco <[hidden email]> wrote:

> From: Bruno Busco <[hidden email]>
> Subject: Re: Discussion: Home application (was: Pluggable preferences/profile screen)
> To: [hidden email], [hidden email]
> Date: Sunday, October 5, 2008, 11:44 AM
> Adrian,
> what you say sounds really great to me.
> It would be nice to have your contribution available to let
> me and others
> contribute and go further.
>
> When you say "a place for it to land" are you
> thinking to something like a
> sandbox folder into SVN may be?
> I think this would be the best and not proceeding with
> patch updating in a
> JIRA issue because it could take some time to get the new
> component stable.
>
> I could also start a Confluence page to write down some
> ideas I have for the
> home application in order to share, discuss, agree and
> implement them all.
> Just give me an OK and I will start the Confluence page.
>
> Thank you,
> -Bruno
>
> 2008/10/5 Adrian Crum <[hidden email]>
>
> > I created a Home application for my employer. The Home
> page has a link to
> > create a new OFBiz user account so that new employees
> can create their own
> > account.
> >
> > A new user is given some basic permissions. Their Home
> page allows them to
> > set preferences, update their profile, and send and
> receive communications.
> > All new users also have access to the calendar
> application and the company
> > forums.
> >
> > I hoped the MyPage component could be used for that,
> but it went off into
> > another direction. I asked Hans if we could keep
> MyPage generic enough for
> > new users to use, but I wasn't successful.
> >
> > I could contribute some of my Home page work to the
> project (in fact, the
> > calendar work I'm doing right now is part of that)
> but we need a place for
> > it to land.
> >
> > -Adrian
> >
> > --- On Sun, 10/5/08, Bruno Busco
> <[hidden email]> wrote:
> >
> > > From: Bruno Busco <[hidden email]>
> > > Subject: Discussion: Home application (was:
> Pluggable preferences/profile
> > screen)
> > > To: [hidden email]
> > > Date: Sunday, October 5, 2008, 2:05 AM
> > > David,
> > > I found in the ML some citations of the Apache
> Pluto
> > > project that is JSR 168
> > > compliant. May be this is what you are referring
> to.
> > > It would be really nice to have the MyPage
> application
> > > rolled out using this
> > > kind of tecnology but I am actually too far from
> having a
> > > clear idea of the
> > > efforts required to do it.
> > >
> > > However I propose to spend some time discussing
> and
> > > collecting requirement
> > > specifications for an application that I feel
> missing into
> > > OFBiz OOTB and
> > > that, may be, is something near to what MyPage
> seems trying
> > > to be.
> > >
> > > I would call the missing application simply
> > > "Home".
> > >
> > > - The main purpose of the Home application would
> be to have
> > > a "solid" access
> > > point to OFBiz that is always accessible to every
> user.
> > > - From this application the user should be able
> to access
> > > all applications
> > > he has permission to.
> > > - Should be directly able (without accessing any
> other
> > > application) to
> > > change his profile and user preferences.
> > > - Should be able to create and configure as many
> > > "dashboard" pages as he
> > > likes. And on every page should be able to put
> screenlets
> > > elements defined
> > > by all installed applications. These features
> extends what
> > > is actually
> > > implemented in MyPage application and, in my
> opinion, gives
> > > a great value to
> > > the entire OFBiz system. (I would use JIRA as a
> model)
> > >
> > > You already said that this kind of things are
> well
> > > implemented into JRS 168
> > > compliant portals but may be it would be better
> to start
> > > defining common
> > > agreed specifications (we could have a JIRA for
> this) and
> > > then, before
> > > starting working, decide if doing it with
> external
> > > tecnologies (like Pluto
> > > for instance) or improving and giving more
> generality to
> > > the actual MyPage
> > > application using the OFBiz screenlets.
> > >
> > > I hope to hear from you all something about that.
> > >
> > > Many thanks,
> > > -Bruno
> > >
> > >
> > > 2008/8/15 David E. Jones
> <[hidden email]>
> > >
> > > >
> > > > While it wouldn't make sense for most of
> OFBiz,
> > > for the MyPage stuff a
> > > > portal framework would be really valuable.
> Many of the
> > > things you
> > > > describe here are basically what a portal
> framework
> > > does (ie the JSR 168
> > > > type of stuff). Other things would have to
> be added on
> > > to make things
> > > > happen automatically based on other stuff in
> OFBiz, ie
> > > some integration
> > > > stuff, but it might be a good idea. There is
> even a
> > > decent little portal
> > > > that is an Apache project...
> > > >
> > > > -David
> > > >
> > > >
> > > > On Fri, 2008-08-15 at 12:41 +0200, Bruno
> Busco wrote:
> > > > > Thinking more about this may be the
> same concept
> > > of pluggability could be
> > > > > used in the MyPage component.
> > > > > Every application could register in
> some way
> > > several own screens that
> > > > will
> > > > > then all available to the user in the
> MyPage.
> > > > > Using the enable/disable checkboxes the
> user coud
> > > configure its "MyPage"
> > > > > picking up things from applications in
> an
> > > application-driven way.
> > > > > -Bruno
> > > > >
> > > > > 2008/8/15 Bruno Busco
> > > <[hidden email]>
> > > > >
> > > > > > Hi all,
> > > > > > while writing the compact header
> we had to
> > > define which links to have
> > > > > > available to the user in the
> compact header
> > > itself.
> > > > > > The "profile" link would
> seem to
> > > be a good candidate (quite standard)
> > > > but,
> > > > > > since the viewprofile page is now
> external
> > > to the framework, this
> > > > offers the
> > > > > > occasion to think about the
> viewprofile and
> > > the preference page itself.
> > > > > >
> > > > > > I have the idea that the
> profile/preference
> > > page could be pluggable.
> > > > > > It is quite common that new
> components have
> > > some new preferences to
> > > > offer
> > > > > > to the user.
> > > > > > Having the profile/preference page
> pluggable
> > > we could let other
> > > > > > applications to add their specific
> elements
> > > to the standard preference
> > > > pages
> > > > > > content.
> > > > > >
> > > > > > The standard
> "preference" page,
> > > defined in the framework, should let
> > > > the
> > > > > > user to change his name, e-mail,
> password,
> > > locale language, timezone,
> > > > > > VisualTheme etc.
> > > > > > Additional applications-defined
> preferences
> > > will be added (in a way to
> > > > be
> > > > > > defined) and shown to the user in
> the same
> > > page of the standard
> > > > preferences
> > > > > > or the like.
> > > > > > A possible way to plug
> application-specific
> > > preferences could be that
> > > > > > application "registers"
> its own
> > > preferences pages adding the path to
> > > > locally
> > > > > > defined preferences screen into a
> globally
> > > framework-defined array.
> > > > > > This array could be used by the
> framework
> > > preference page to populate a
> > > > > > TabBarMenu so that all
> applications
> > > preferences will be available at
> > > > one
> > > > > > place.
> > > > > >
> > > > > > What do you think about?
> > > > > > Thanks,
> > > > > > -Bruno
> > > > > >
> > > >
> > > >
> >
> >
> >
> >

     

[BJ Freeman]

Not to discount your suggestion, I have been told over and over that
ofbiz needs to stay generic. Also that projects should be of the
community, not the submitter.
Based on that view, I believe the Mypage should be allow more community
input and/or add more to the page that the community says is desired.
I was also hoping that the my page would become the place the login
person would go to.
I would like to see your work folded into the Mypage, by adding your
Home page to the Mypage folder as an alternative.


Adrian Crum wrote:

> I created a Home application for my employer. The Home page has a link to create a new OFBiz user account so that new employees can create their own account.
>
> A new user is given some basic permissions. Their Home page allows them to set preferences, update their profile, and send and receive communications. All new users also have access to the calendar application and the company forums.
>
> I hoped the MyPage component could be used for that, but it went off into another direction. I asked Hans if we could keep MyPage generic enough for new users to use, but I wasn't successful.
>
> I could contribute some of my Home page work to the project (in fact, the calendar work I'm doing right now is part of that) but we need a place for it to land.
>
> -Adrian
>
> --- On Sun, 10/5/08, Bruno Busco <[hidden email]> wrote:
>
>> From: Bruno Busco <[hidden email]>
>> Subject: Discussion: Home application (was: Pluggable preferences/profile screen)
>> To: [hidden email]
>> Date: Sunday, October 5, 2008, 2:05 AM
>> David,
>> I found in the ML some citations of the Apache Pluto
>> project that is JSR 168
>> compliant. May be this is what you are referring to.
>> It would be really nice to have the MyPage application
>> rolled out using this
>> kind of tecnology but I am actually too far from having a
>> clear idea of the
>> efforts required to do it.
>>
>> However I propose to spend some time discussing and
>> collecting requirement
>> specifications for an application that I feel missing into
>> OFBiz OOTB and
>> that, may be, is something near to what MyPage seems trying
>> to be.
>>
>> I would call the missing application simply
>> "Home".
>>
>> - The main purpose of the Home application would be to have
>> a "solid" access
>> point to OFBiz that is always accessible to every user.
>> - From this application the user should be able to access
>> all applications
>> he has permission to.
>> - Should be directly able (without accessing any other
>> application) to
>> change his profile and user preferences.
>> - Should be able to create and configure as many
>> "dashboard" pages as he
>> likes. And on every page should be able to put screenlets
>> elements defined
>> by all installed applications. These features extends what
>> is actually
>> implemented in MyPage application and, in my opinion, gives
>> a great value to
>> the entire OFBiz system. (I would use JIRA as a model)
>>
>> You already said that this kind of things are well
>> implemented into JRS 168
>> compliant portals but may be it would be better to start
>> defining common
>> agreed specifications (we could have a JIRA for this) and
>> then, before
>> starting working, decide if doing it with external
>> tecnologies (like Pluto
>> for instance) or improving and giving more generality to
>> the actual MyPage
>> application using the OFBiz screenlets.
>>
>> I hope to hear from you all something about that.
>>
>> Many thanks,
>> -Bruno
>>
>>
>> 2008/8/15 David E. Jones <[hidden email]>
>>
>>> While it wouldn't make sense for most of OFBiz,
>> for the MyPage stuff a
>>> portal framework would be really valuable. Many of the
>> things you
>>> describe here are basically what a portal framework
>> does (ie the JSR 168
>>> type of stuff). Other things would have to be added on
>> to make things
>>> happen automatically based on other stuff in OFBiz, ie
>> some integration
>>> stuff, but it might be a good idea. There is even a
>> decent little portal
>>> that is an Apache project...
>>>
>>> -David
>>>
>>>
>>> On Fri, 2008-08-15 at 12:41 +0200, Bruno Busco wrote:
>>>> Thinking more about this may be the same concept
>> of pluggability could be
>>>> used in the MyPage component.
>>>> Every application could register in some way
>> several own screens that
>>> will
>>>> then all available to the user in the MyPage.
>>>> Using the enable/disable checkboxes the user coud
>> configure its "MyPage"
>>>> picking up things from applications in an
>> application-driven way.
>>>> -Bruno
>>>>
>>>> 2008/8/15 Bruno Busco
>> <[hidden email]>
>>>>> Hi all,
>>>>> while writing the compact header we had to
>> define which links to have
>>>>> available to the user in the compact header
>> itself.
>>>>> The "profile" link would seem to
>> be a good candidate (quite standard)
>>> but,
>>>>> since the viewprofile page is now external
>> to the framework, this
>>> offers the
>>>>> occasion to think about the viewprofile and
>> the preference page itself.
>>>>> I have the idea that the profile/preference
>> page could be pluggable.
>>>>> It is quite common that new components have
>> some new preferences to
>>> offer
>>>>> to the user.
>>>>> Having the profile/preference page pluggable
>> we could let other
>>>>> applications to add their specific elements
>> to the standard preference
>>> pages
>>>>> content.
>>>>>
>>>>> The standard "preference" page,
>> defined in the framework, should let
>>> the
>>>>> user to change his name, e-mail, password,
>> locale language, timezone,
>>>>> VisualTheme etc.
>>>>> Additional applications-defined preferences
>> will be added (in a way to
>>> be
>>>>> defined) and shown to the user in the same
>> page of the standard
>>> preferences
>>>>> or the like.
>>>>> A possible way to plug application-specific
>> preferences could be that
>>>>> application "registers" its own
>> preferences pages adding the path to
>>> locally
>>>>> defined preferences screen into a globally
>> framework-defined array.
>>>>> This array could be used by the framework
>> preference page to populate a
>>>>> TabBarMenu so that all applications
>> preferences will be available at
>>> one
>>>>> place.
>>>>>
>>>>> What do you think about?
>>>>> Thanks,
>>>>> -Bruno
>>>>>
>>>
>
>
>      
>
>