You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tapestry.apache.org by "Andreas Andreou (JIRA)" <ji...@apache.org> on 2011/01/19 21:51:48 UTC
[jira] Commented: (TAP5-1421) Create a standard way to track
messages to be presented to the user
[ https://issues.apache.org/jira/browse/TAP5-1421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983883#action_12983883 ]
Andreas Andreou commented on TAP5-1421:
---------------------------------------
Isn't it best to keep something like this out of the core?
> Create a standard way to track messages to be presented to the user
> -------------------------------------------------------------------
>
> Key: TAP5-1421
> URL: https://issues.apache.org/jira/browse/TAP5-1421
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-core
> Reporter: Howard M. Lewis Ship
> Priority: Minor
>
> For a client, I've created a GlobalAlerts SSO, along with a GlobalAlertsManager service, an Alerts component, even JavaScript client-side support for adding and clearing alerts. I'd like to generalize this code a bit ... currently Alerts messages are limited to strings (fully renderable would be better).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (TAP5-1421) Create a standard way to track
messages to be presented to the user
Posted by Howard Lewis Ship <hl...@gmail.com>.
Splitting tapestry-core into sub-modules in non-trivial, there's a bit
of a rat's nest of dependencies between components and services and
other components and other even hard to quantify things!
On Thu, Jan 20, 2011 at 4:49 PM, Bob Harner <bo...@gmail.com> wrote:
> Josh's approach sounds ideal to me. Maven makes it easy to aggregate many
> small pieces, but splitting up a monolithic core only gets harder over time.
> On Jan 20, 2011 6:38 PM, "Robert Zeigler" <ro...@roxanemy.com>
> wrote:
>> +1 to leaner, lighter-weight modules, and a maven dependency that has all
> (almost?) of the tapestry modules as dependencies. Becomes easier to pick
> and choose at that point; you can explicitly include a small number of
> modules, or depend on tapestry-kitchensink and exclude a few pieces that you
> don't want/need. The quickstart archetype would either add all of the
> "important" dependencies, or else add a dependency on the "kitchen sink".
>>
>> Robert
>>
>> On Jan 20, 2011, at 1/205:31 PM , Josh Canfield wrote:
>>
>>>> So what are the advantages/disadvantages of having another module at
>>>> apache, say, tapestry-stdlib vs. just moving such a component into
>>>> tapestry-core?
>>>
>>> Bloat is a disadvantage to continue putting things into tapestry-core,
>>> both from a size of dependency as well as a maintenance standpoint.
>>>
>>> You can build the tapestry-kitchensink (not really what I would
>>> consider core) module that has compile dependencies on everything, but
>>> mostly I'd like to include the leanest meanest dependencies possible.
>>>
>>> To the extreme, I'd go so far as to say that I'd like to separate out
>>> * tapestry-ioc - IOC container
>>> * tapestry-servlets - Servlet request processing
>>> * tapestry-templates - Component/page rendering code (t:block,
>>> t:container, t:body, etc... i.e. non-component based template
>>> elements)
>>> * tapestry-components - Core components (t:if, t:unless, t:loop, t:any,
> t:zone)
>>> * tapestry-forms - Form components (t:form, t:textfield, etc.)
>>> * tapestry-beaneditor - BeanEditor components
>>> * tapestry-gridview - Grid components
>>> * tapestry-usermessages - User message tracking components
>>> * etc.
>>>
>>> Deciding how large a feature needs to be in order to get it's own
>>> module is debatable. (AjaxFormLoop?)
>>>
>>> I'm working on a project now that would just use tapestry-(ioc |
>>> servlets | hibernate | resteasy) (and tapestry-monitoring, but that's
>>> in the works!).
>>>
>>> There _is_ a value to having a simple single dependency that a
>>> Tapestry and possibly Java newbie could use to rip through a tutorial,
>>> write the tutorial such that a single entry pointing at the
>>> kitchen-sink module in the pom and all the transient dependencies are
>>> sucked down with it.
>>>
>>> An example of a project with lots of extensions is the Restlet API.
>>> While the docs in general are not great, they have an impressive list
>>> of extensions:
> http://wiki.restlet.org/docs_2.0/13-restlet/28-restlet.html.
>>>
>>>
>>> Josh
>>>
>>> On Thu, Jan 20, 2011 at 12:52 PM, Howard Lewis Ship <hl...@gmail.com>
> wrote:
>>>> So what are the advantages/disadvantages of having another module at
>>>> apache, say, tapestry-stdlib vs. just moving such a component into
>>>> tapestry-core?
>>>>
>>>> To me, the idea of saying "if you want to present confirmation to a
>>>> user, just use the AlertsManager and Alerts component" is more
>>>> satisifying in a tutorial than saying "create a flash-scoped message
>>>> field, etc., etc.,". However, if the AlertsManager is in a optional
>>>> library, I might not feel as good about referencing it in a tutorial
>>>> compared to if it was in tapestry-core. And if we end up effectively
>>>> mandating the user of tapestry-stdllib, how valuable is it separate
>>>> from tapestry-core.
>>>>
>>>> Alternately, if we have a stdlib, do we move some of our existing
>>>> components and mixins out of core?
>>>>
>>>>
>>>> On Thu, Jan 20, 2011 at 12:44 PM, Thiago H. de Paula Figueiredo
>>>> <th...@gmail.com> wrote:
>>>>> On Thu, 20 Jan 2011 16:37:47 -0200, Josh Canfield <
> joshcanfield@gmail.com>
>>>>> wrote:
>>>>>
>>>>>>> Alternately, perhaps we need to resuscitate the idea of a standard
>>>>>>> library (or libraries) beyond core.
>>>>>>
>>>>>> My gut tells me to pull as much of the system apart into independent
>>>>>> modules as possible. Smaller is better, easier to understand, easier
>>>>>> to test.
>>>>>
>>>>> Please do it as a Tapestry subproject (tapestry-morecomponents?)
> instead of
>>>>> TapX or other external packages. It seems to me that people consider
>>>>> anything outside the Tapestry project, even being linked from there, as
> not
>>>>> part of the out-of-the-box experience. Something like "feature X is so
>>>>> important, but I need a third-party package to have it" (something used
> a
>>>>> lot to criticize JSF).
>>>>>
>>>>> --
>>>>> Thiago H. de Paula Figueiredo
>>>>> Independent Java, Apache Tapestry 5 and Hibernate consultant,
> developer, and
>>>>> instructor
>>>>> Owner, Ars Machina Tecnologia da Informação Ltda.
>>>>> http://www.arsmachina.com.br
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Howard M. Lewis Ship
>>>>
>>>> Creator of Apache Tapestry
>>>>
>>>> The source for Tapestry training, mentoring and support. Contact me to
>>>> learn how I can get you up and productive in Tapestry fast!
>>>>
>>>> (971) 678-5210
>>>> http://howardlewisship.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [jira] Commented: (TAP5-1421) Create a standard way to track
messages to be presented to the user
Posted by Bob Harner <bo...@gmail.com>.
Josh's approach sounds ideal to me. Maven makes it easy to aggregate many
small pieces, but splitting up a monolithic core only gets harder over time.
On Jan 20, 2011 6:38 PM, "Robert Zeigler" <ro...@roxanemy.com>
wrote:
> +1 to leaner, lighter-weight modules, and a maven dependency that has all
(almost?) of the tapestry modules as dependencies. Becomes easier to pick
and choose at that point; you can explicitly include a small number of
modules, or depend on tapestry-kitchensink and exclude a few pieces that you
don't want/need. The quickstart archetype would either add all of the
"important" dependencies, or else add a dependency on the "kitchen sink".
>
> Robert
>
> On Jan 20, 2011, at 1/205:31 PM , Josh Canfield wrote:
>
>>> So what are the advantages/disadvantages of having another module at
>>> apache, say, tapestry-stdlib vs. just moving such a component into
>>> tapestry-core?
>>
>> Bloat is a disadvantage to continue putting things into tapestry-core,
>> both from a size of dependency as well as a maintenance standpoint.
>>
>> You can build the tapestry-kitchensink (not really what I would
>> consider core) module that has compile dependencies on everything, but
>> mostly I'd like to include the leanest meanest dependencies possible.
>>
>> To the extreme, I'd go so far as to say that I'd like to separate out
>> * tapestry-ioc - IOC container
>> * tapestry-servlets - Servlet request processing
>> * tapestry-templates - Component/page rendering code (t:block,
>> t:container, t:body, etc... i.e. non-component based template
>> elements)
>> * tapestry-components - Core components (t:if, t:unless, t:loop, t:any,
t:zone)
>> * tapestry-forms - Form components (t:form, t:textfield, etc.)
>> * tapestry-beaneditor - BeanEditor components
>> * tapestry-gridview - Grid components
>> * tapestry-usermessages - User message tracking components
>> * etc.
>>
>> Deciding how large a feature needs to be in order to get it's own
>> module is debatable. (AjaxFormLoop?)
>>
>> I'm working on a project now that would just use tapestry-(ioc |
>> servlets | hibernate | resteasy) (and tapestry-monitoring, but that's
>> in the works!).
>>
>> There _is_ a value to having a simple single dependency that a
>> Tapestry and possibly Java newbie could use to rip through a tutorial,
>> write the tutorial such that a single entry pointing at the
>> kitchen-sink module in the pom and all the transient dependencies are
>> sucked down with it.
>>
>> An example of a project with lots of extensions is the Restlet API.
>> While the docs in general are not great, they have an impressive list
>> of extensions:
http://wiki.restlet.org/docs_2.0/13-restlet/28-restlet.html.
>>
>>
>> Josh
>>
>> On Thu, Jan 20, 2011 at 12:52 PM, Howard Lewis Ship <hl...@gmail.com>
wrote:
>>> So what are the advantages/disadvantages of having another module at
>>> apache, say, tapestry-stdlib vs. just moving such a component into
>>> tapestry-core?
>>>
>>> To me, the idea of saying "if you want to present confirmation to a
>>> user, just use the AlertsManager and Alerts component" is more
>>> satisifying in a tutorial than saying "create a flash-scoped message
>>> field, etc., etc.,". However, if the AlertsManager is in a optional
>>> library, I might not feel as good about referencing it in a tutorial
>>> compared to if it was in tapestry-core. And if we end up effectively
>>> mandating the user of tapestry-stdllib, how valuable is it separate
>>> from tapestry-core.
>>>
>>> Alternately, if we have a stdlib, do we move some of our existing
>>> components and mixins out of core?
>>>
>>>
>>> On Thu, Jan 20, 2011 at 12:44 PM, Thiago H. de Paula Figueiredo
>>> <th...@gmail.com> wrote:
>>>> On Thu, 20 Jan 2011 16:37:47 -0200, Josh Canfield <
joshcanfield@gmail.com>
>>>> wrote:
>>>>
>>>>>> Alternately, perhaps we need to resuscitate the idea of a standard
>>>>>> library (or libraries) beyond core.
>>>>>
>>>>> My gut tells me to pull as much of the system apart into independent
>>>>> modules as possible. Smaller is better, easier to understand, easier
>>>>> to test.
>>>>
>>>> Please do it as a Tapestry subproject (tapestry-morecomponents?)
instead of
>>>> TapX or other external packages. It seems to me that people consider
>>>> anything outside the Tapestry project, even being linked from there, as
not
>>>> part of the out-of-the-box experience. Something like "feature X is so
>>>> important, but I need a third-party package to have it" (something used
a
>>>> lot to criticize JSF).
>>>>
>>>> --
>>>> Thiago H. de Paula Figueiredo
>>>> Independent Java, Apache Tapestry 5 and Hibernate consultant,
developer, and
>>>> instructor
>>>> Owner, Ars Machina Tecnologia da Informação Ltda.
>>>> http://www.arsmachina.com.br
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Howard M. Lewis Ship
>>>
>>> Creator of Apache Tapestry
>>>
>>> The source for Tapestry training, mentoring and support. Contact me to
>>> learn how I can get you up and productive in Tapestry fast!
>>>
>>> (971) 678-5210
>>> http://howardlewisship.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
Re: [jira] Commented: (TAP5-1421) Create a standard way to track messages to be presented to the user
Posted by Robert Zeigler <ro...@roxanemy.com>.
+1 to leaner, lighter-weight modules, and a maven dependency that has all (almost?) of the tapestry modules as dependencies. Becomes easier to pick and choose at that point; you can explicitly include a small number of modules, or depend on tapestry-kitchensink and exclude a few pieces that you don't want/need. The quickstart archetype would either add all of the "important" dependencies, or else add a dependency on the "kitchen sink".
Robert
On Jan 20, 2011, at 1/205:31 PM , Josh Canfield wrote:
>> So what are the advantages/disadvantages of having another module at
>> apache, say, tapestry-stdlib vs. just moving such a component into
>> tapestry-core?
>
> Bloat is a disadvantage to continue putting things into tapestry-core,
> both from a size of dependency as well as a maintenance standpoint.
>
> You can build the tapestry-kitchensink (not really what I would
> consider core) module that has compile dependencies on everything, but
> mostly I'd like to include the leanest meanest dependencies possible.
>
> To the extreme, I'd go so far as to say that I'd like to separate out
> * tapestry-ioc - IOC container
> * tapestry-servlets - Servlet request processing
> * tapestry-templates - Component/page rendering code (t:block,
> t:container, t:body, etc... i.e. non-component based template
> elements)
> * tapestry-components - Core components (t:if, t:unless, t:loop, t:any, t:zone)
> * tapestry-forms - Form components (t:form, t:textfield, etc.)
> * tapestry-beaneditor - BeanEditor components
> * tapestry-gridview - Grid components
> * tapestry-usermessages - User message tracking components
> * etc.
>
> Deciding how large a feature needs to be in order to get it's own
> module is debatable. (AjaxFormLoop?)
>
> I'm working on a project now that would just use tapestry-(ioc |
> servlets | hibernate | resteasy) (and tapestry-monitoring, but that's
> in the works!).
>
> There _is_ a value to having a simple single dependency that a
> Tapestry and possibly Java newbie could use to rip through a tutorial,
> write the tutorial such that a single entry pointing at the
> kitchen-sink module in the pom and all the transient dependencies are
> sucked down with it.
>
> An example of a project with lots of extensions is the Restlet API.
> While the docs in general are not great, they have an impressive list
> of extensions: http://wiki.restlet.org/docs_2.0/13-restlet/28-restlet.html.
>
>
> Josh
>
> On Thu, Jan 20, 2011 at 12:52 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
>> So what are the advantages/disadvantages of having another module at
>> apache, say, tapestry-stdlib vs. just moving such a component into
>> tapestry-core?
>>
>> To me, the idea of saying "if you want to present confirmation to a
>> user, just use the AlertsManager and Alerts component" is more
>> satisifying in a tutorial than saying "create a flash-scoped message
>> field, etc., etc.,". However, if the AlertsManager is in a optional
>> library, I might not feel as good about referencing it in a tutorial
>> compared to if it was in tapestry-core. And if we end up effectively
>> mandating the user of tapestry-stdllib, how valuable is it separate
>> from tapestry-core.
>>
>> Alternately, if we have a stdlib, do we move some of our existing
>> components and mixins out of core?
>>
>>
>> On Thu, Jan 20, 2011 at 12:44 PM, Thiago H. de Paula Figueiredo
>> <th...@gmail.com> wrote:
>>> On Thu, 20 Jan 2011 16:37:47 -0200, Josh Canfield <jo...@gmail.com>
>>> wrote:
>>>
>>>>> Alternately, perhaps we need to resuscitate the idea of a standard
>>>>> library (or libraries) beyond core.
>>>>
>>>> My gut tells me to pull as much of the system apart into independent
>>>> modules as possible. Smaller is better, easier to understand, easier
>>>> to test.
>>>
>>> Please do it as a Tapestry subproject (tapestry-morecomponents?) instead of
>>> TapX or other external packages. It seems to me that people consider
>>> anything outside the Tapestry project, even being linked from there, as not
>>> part of the out-of-the-box experience. Something like "feature X is so
>>> important, but I need a third-party package to have it" (something used a
>>> lot to criticize JSF).
>>>
>>> --
>>> Thiago H. de Paula Figueiredo
>>> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and
>>> instructor
>>> Owner, Ars Machina Tecnologia da Informação Ltda.
>>> http://www.arsmachina.com.br
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Howard M. Lewis Ship
>>
>> Creator of Apache Tapestry
>>
>> The source for Tapestry training, mentoring and support. Contact me to
>> learn how I can get you up and productive in Tapestry fast!
>>
>> (971) 678-5210
>> http://howardlewisship.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [jira] Commented: (TAP5-1421) Create a standard way to track
messages to be presented to the user
Posted by Massimo Lusetti <ml...@gmail.com>.
On Fri, Jan 21, 2011 at 12:31 AM, Josh Canfield <jo...@gmail.com> wrote:
> To the extreme, I'd go so far as to say that I'd like to separate out
> * tapestry-ioc - IOC container
> * tapestry-servlets - Servlet request processing
> * tapestry-templates - Component/page rendering code (t:block,
> t:container, t:body, etc... i.e. non-component based template
> elements)
> * tapestry-components - Core components (t:if, t:unless, t:loop, t:any, t:zone)
> * tapestry-forms - Form components (t:form, t:textfield, etc.)
> * tapestry-beaneditor - BeanEditor components
> * tapestry-gridview - Grid components
> * tapestry-usermessages - User message tracking components
> * etc.
Definitely too much. I don't want to have a guide on where to find the
components I need.
I read "to the extreme" but that path brings you with a lot of
fragmentation that is as much evil as the monolithic paradigm.
No one want to bloat -core but I stand besides Igor.
Cheers
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [jira] Commented: (TAP5-1421) Create a standard way to track
messages to be presented to the user
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Thu, 20 Jan 2011 21:31:47 -0200, Josh Canfield <jo...@gmail.com>
wrote:
> To the extreme, I'd go so far as to say that I'd like to separate out
> * tapestry-ioc - IOC container
> * tapestry-servlets - Servlet request processing
> * tapestry-templates - Component/page rendering code (t:block,
> t:container, t:body, etc... i.e. non-component based template
> elements)
> * tapestry-components - Core components (t:if, t:unless, t:loop, t:any,
> t:zone)
> * tapestry-forms - Form components (t:form, t:textfield, etc.)
> * tapestry-beaneditor - BeanEditor components
> * tapestry-gridview - Grid components
> * tapestry-usermessages - User message tracking components
> * etc.
I think this is too extreme. I guess it would be very confusing for new
users to figure out what does he/she needs. In addition, each new module
has some overhead from the Tapestry team side. In addition, I don't
consider the current core JAR too large or bloated.
I can't see why the components library itself would be separated in
another project. It's almost impossible to have an useful Tapestry
application without them. In the above example, as Howard said about
dissecting the core jar, both BeanEditor and Grid have the same base:
BeanModel.
My suggestion: keep the core as is and discuss the placement of new
components and services and the creation of another modules case by case.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [jira] Commented: (TAP5-1421) Create a standard way to track
messages to be presented to the user
Posted by Josh Canfield <jo...@gmail.com>.
> So what are the advantages/disadvantages of having another module at
> apache, say, tapestry-stdlib vs. just moving such a component into
> tapestry-core?
Bloat is a disadvantage to continue putting things into tapestry-core,
both from a size of dependency as well as a maintenance standpoint.
You can build the tapestry-kitchensink (not really what I would
consider core) module that has compile dependencies on everything, but
mostly I'd like to include the leanest meanest dependencies possible.
To the extreme, I'd go so far as to say that I'd like to separate out
* tapestry-ioc - IOC container
* tapestry-servlets - Servlet request processing
* tapestry-templates - Component/page rendering code (t:block,
t:container, t:body, etc... i.e. non-component based template
elements)
* tapestry-components - Core components (t:if, t:unless, t:loop, t:any, t:zone)
* tapestry-forms - Form components (t:form, t:textfield, etc.)
* tapestry-beaneditor - BeanEditor components
* tapestry-gridview - Grid components
* tapestry-usermessages - User message tracking components
* etc.
Deciding how large a feature needs to be in order to get it's own
module is debatable. (AjaxFormLoop?)
I'm working on a project now that would just use tapestry-(ioc |
servlets | hibernate | resteasy) (and tapestry-monitoring, but that's
in the works!).
There _is_ a value to having a simple single dependency that a
Tapestry and possibly Java newbie could use to rip through a tutorial,
write the tutorial such that a single entry pointing at the
kitchen-sink module in the pom and all the transient dependencies are
sucked down with it.
An example of a project with lots of extensions is the Restlet API.
While the docs in general are not great, they have an impressive list
of extensions: http://wiki.restlet.org/docs_2.0/13-restlet/28-restlet.html.
Josh
On Thu, Jan 20, 2011 at 12:52 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> So what are the advantages/disadvantages of having another module at
> apache, say, tapestry-stdlib vs. just moving such a component into
> tapestry-core?
>
> To me, the idea of saying "if you want to present confirmation to a
> user, just use the AlertsManager and Alerts component" is more
> satisifying in a tutorial than saying "create a flash-scoped message
> field, etc., etc.,". However, if the AlertsManager is in a optional
> library, I might not feel as good about referencing it in a tutorial
> compared to if it was in tapestry-core. And if we end up effectively
> mandating the user of tapestry-stdllib, how valuable is it separate
> from tapestry-core.
>
> Alternately, if we have a stdlib, do we move some of our existing
> components and mixins out of core?
>
>
> On Thu, Jan 20, 2011 at 12:44 PM, Thiago H. de Paula Figueiredo
> <th...@gmail.com> wrote:
>> On Thu, 20 Jan 2011 16:37:47 -0200, Josh Canfield <jo...@gmail.com>
>> wrote:
>>
>>>> Alternately, perhaps we need to resuscitate the idea of a standard
>>>> library (or libraries) beyond core.
>>>
>>> My gut tells me to pull as much of the system apart into independent
>>> modules as possible. Smaller is better, easier to understand, easier
>>> to test.
>>
>> Please do it as a Tapestry subproject (tapestry-morecomponents?) instead of
>> TapX or other external packages. It seems to me that people consider
>> anything outside the Tapestry project, even being linked from there, as not
>> part of the out-of-the-box experience. Something like "feature X is so
>> important, but I need a third-party package to have it" (something used a
>> lot to criticize JSF).
>>
>> --
>> Thiago H. de Paula Figueiredo
>> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and
>> instructor
>> Owner, Ars Machina Tecnologia da Informação Ltda.
>> http://www.arsmachina.com.br
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [jira] Commented: (TAP5-1421) Create a standard way to track
messages to be presented to the user
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Thu, 20 Jan 2011 18:52:29 -0200, Howard Lewis Ship <hl...@gmail.com>
wrote:
> So what are the advantages/disadvantages of having another module at
> apache, say, tapestry-stdlib vs. just moving such a component into
> tapestry-core?
To me, a separate module would be the place for functionality that is
important to have ready to use but, at the same time, not used in most
project. I hope I'm not contradicting myself here. :) One exemple: suppose
there's no licensing issues to have some cool components using the Google
Maps API inside the Tapestry project. As Igor said, this would be an
appealing feature, but not used in most projects, so it should be in a
tapestry-extras module.
> To me, the idea of saying "if you want to present confirmation to a
> user, just use the AlertsManager and Alerts component" is more
> satisifying in a tutorial than saying "create a flash-scoped message
> field, etc., etc.,". However, if the AlertsManager is in a optional
> library, I might not feel as good about referencing it in a tutorial
> compared to if it was in tapestry-core.
Not as good, but not much as long as it's explained it's part of the
Tapestry project and how to include it in a project (Maven, Gradle, Ivy,
etc).
> And if we end up effectively
> mandating the user of tapestry-stdllib, how valuable is it separate
> from tapestry-core.
Agreed.
> Alternately, if we have a stdlib, do we move some of our existing
> components and mixins out of core?
I don't think so, hence my suggestion of a tapestry-extras module.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [jira] Commented: (TAP5-1421) Create a standard way to track
messages to be presented to the user
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Thu, 20 Jan 2011 19:00:09 -0200, Igor Drobiazko
<ig...@gmail.com> wrote:
> I would love to see even more components inside core. A rich set of
> components is the most appealing feature for a component-oriented
> framework. The more out-of-the box components available the better.
Agreed, but what meaning do we use for "out-of-the-box"? Inside
tapestry-core? Or also including anything that is provided as a Tapestry
subproject? My vote is for the second meaning, specially when Tapestry-IoC
makes it just a matter of including the JAR in the classpath.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [jira] Commented: (TAP5-1421) Create a standard way to track
messages to be presented to the user
Posted by Ulrich Stärk <ul...@spielviel.de>.
I second that.
On 20.01.2011 22:00, Igor Drobiazko wrote:
> I would love to see even more components inside core. A rich set of
> components is the most appealing feature for a component-oriented framework.
> The more out-of-the box components available the better.
>
> On Thu, Jan 20, 2011 at 9:52 PM, Howard Lewis Ship<hl...@gmail.com> wrote:
>
>> So what are the advantages/disadvantages of having another module at
>> apache, say, tapestry-stdlib vs. just moving such a component into
>> tapestry-core?
>>
>> To me, the idea of saying "if you want to present confirmation to a
>> user, just use the AlertsManager and Alerts component" is more
>> satisifying in a tutorial than saying "create a flash-scoped message
>> field, etc., etc.,". However, if the AlertsManager is in a optional
>> library, I might not feel as good about referencing it in a tutorial
>> compared to if it was in tapestry-core. And if we end up effectively
>> mandating the user of tapestry-stdllib, how valuable is it separate
>> from tapestry-core.
>>
>> Alternately, if we have a stdlib, do we move some of our existing
>> components and mixins out of core?
>>
>>
>> On Thu, Jan 20, 2011 at 12:44 PM, Thiago H. de Paula Figueiredo
>> <th...@gmail.com> wrote:
>>> On Thu, 20 Jan 2011 16:37:47 -0200, Josh Canfield<
>> joshcanfield@gmail.com>
>>> wrote:
>>>
>>>>> Alternately, perhaps we need to resuscitate the idea of a standard
>>>>> library (or libraries) beyond core.
>>>>
>>>> My gut tells me to pull as much of the system apart into independent
>>>> modules as possible. Smaller is better, easier to understand, easier
>>>> to test.
>>>
>>> Please do it as a Tapestry subproject (tapestry-morecomponents?) instead
>> of
>>> TapX or other external packages. It seems to me that people consider
>>> anything outside the Tapestry project, even being linked from there, as
>> not
>>> part of the out-of-the-box experience. Something like "feature X is so
>>> important, but I need a third-party package to have it" (something used a
>>> lot to criticize JSF).
>>>
>>> --
>>> Thiago H. de Paula Figueiredo
>>> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
>> and
>>> instructor
>>> Owner, Ars Machina Tecnologia da Informação Ltda.
>>> http://www.arsmachina.com.br
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Howard M. Lewis Ship
>>
>> Creator of Apache Tapestry
>>
>> The source for Tapestry training, mentoring and support. Contact me to
>> learn how I can get you up and productive in Tapestry fast!
>>
>> (971) 678-5210
>> http://howardlewisship.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [jira] Commented: (TAP5-1421) Create a standard way to track
messages to be presented to the user
Posted by Igor Drobiazko <ig...@gmail.com>.
I would love to see even more components inside core. A rich set of
components is the most appealing feature for a component-oriented framework.
The more out-of-the box components available the better.
On Thu, Jan 20, 2011 at 9:52 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> So what are the advantages/disadvantages of having another module at
> apache, say, tapestry-stdlib vs. just moving such a component into
> tapestry-core?
>
> To me, the idea of saying "if you want to present confirmation to a
> user, just use the AlertsManager and Alerts component" is more
> satisifying in a tutorial than saying "create a flash-scoped message
> field, etc., etc.,". However, if the AlertsManager is in a optional
> library, I might not feel as good about referencing it in a tutorial
> compared to if it was in tapestry-core. And if we end up effectively
> mandating the user of tapestry-stdllib, how valuable is it separate
> from tapestry-core.
>
> Alternately, if we have a stdlib, do we move some of our existing
> components and mixins out of core?
>
>
> On Thu, Jan 20, 2011 at 12:44 PM, Thiago H. de Paula Figueiredo
> <th...@gmail.com> wrote:
> > On Thu, 20 Jan 2011 16:37:47 -0200, Josh Canfield <
> joshcanfield@gmail.com>
> > wrote:
> >
> >>> Alternately, perhaps we need to resuscitate the idea of a standard
> >>> library (or libraries) beyond core.
> >>
> >> My gut tells me to pull as much of the system apart into independent
> >> modules as possible. Smaller is better, easier to understand, easier
> >> to test.
> >
> > Please do it as a Tapestry subproject (tapestry-morecomponents?) instead
> of
> > TapX or other external packages. It seems to me that people consider
> > anything outside the Tapestry project, even being linked from there, as
> not
> > part of the out-of-the-box experience. Something like "feature X is so
> > important, but I need a third-party package to have it" (something used a
> > lot to criticize JSF).
> >
> > --
> > Thiago H. de Paula Figueiredo
> > Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
> and
> > instructor
> > Owner, Ars Machina Tecnologia da Informação Ltda.
> > http://www.arsmachina.com.br
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Best regards,
Igor Drobiazko
http://tapestry5.de
Re: [jira] Commented: (TAP5-1421) Create a standard way to track
messages to be presented to the user
Posted by Howard Lewis Ship <hl...@gmail.com>.
So what are the advantages/disadvantages of having another module at
apache, say, tapestry-stdlib vs. just moving such a component into
tapestry-core?
To me, the idea of saying "if you want to present confirmation to a
user, just use the AlertsManager and Alerts component" is more
satisifying in a tutorial than saying "create a flash-scoped message
field, etc., etc.,". However, if the AlertsManager is in a optional
library, I might not feel as good about referencing it in a tutorial
compared to if it was in tapestry-core. And if we end up effectively
mandating the user of tapestry-stdllib, how valuable is it separate
from tapestry-core.
Alternately, if we have a stdlib, do we move some of our existing
components and mixins out of core?
On Thu, Jan 20, 2011 at 12:44 PM, Thiago H. de Paula Figueiredo
<th...@gmail.com> wrote:
> On Thu, 20 Jan 2011 16:37:47 -0200, Josh Canfield <jo...@gmail.com>
> wrote:
>
>>> Alternately, perhaps we need to resuscitate the idea of a standard
>>> library (or libraries) beyond core.
>>
>> My gut tells me to pull as much of the system apart into independent
>> modules as possible. Smaller is better, easier to understand, easier
>> to test.
>
> Please do it as a Tapestry subproject (tapestry-morecomponents?) instead of
> TapX or other external packages. It seems to me that people consider
> anything outside the Tapestry project, even being linked from there, as not
> part of the out-of-the-box experience. Something like "feature X is so
> important, but I need a third-party package to have it" (something used a
> lot to criticize JSF).
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and
> instructor
> Owner, Ars Machina Tecnologia da Informação Ltda.
> http://www.arsmachina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [jira] Commented: (TAP5-1421) Create a standard way to track messages to be presented to the user
Posted by Robert Zeigler <ro...@roxanemy.com>.
Also in favor of a separate tapestry subproject. The fact that there are multiple pieces (service(s), component(s), js, etc.) all coordinating together really makes it sound like this is appropriate as a standalone module, outside of core.
Robert
On Jan 20, 2011, at 1/202:44 PM , Thiago H. de Paula Figueiredo wrote:
> On Thu, 20 Jan 2011 16:37:47 -0200, Josh Canfield <jo...@gmail.com> wrote:
>
>>> Alternately, perhaps we need to resuscitate the idea of a standard
>>> library (or libraries) beyond core.
>>
>> My gut tells me to pull as much of the system apart into independent
>> modules as possible. Smaller is better, easier to understand, easier
>> to test.
>
> Please do it as a Tapestry subproject (tapestry-morecomponents?) instead of TapX or other external packages. It seems to me that people consider anything outside the Tapestry project, even being linked from there, as not part of the out-of-the-box experience. Something like "feature X is so important, but I need a third-party package to have it" (something used a lot to criticize JSF).
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor
> Owner, Ars Machina Tecnologia da Informação Ltda.
> http://www.arsmachina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [jira] Commented: (TAP5-1421) Create a standard way to track
messages to be presented to the user
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Thu, 20 Jan 2011 16:37:47 -0200, Josh Canfield <jo...@gmail.com>
wrote:
>> Alternately, perhaps we need to resuscitate the idea of a standard
>> library (or libraries) beyond core.
>
> My gut tells me to pull as much of the system apart into independent
> modules as possible. Smaller is better, easier to understand, easier
> to test.
Please do it as a Tapestry subproject (tapestry-morecomponents?) instead
of TapX or other external packages. It seems to me that people consider
anything outside the Tapestry project, even being linked from there, as
not part of the out-of-the-box experience. Something like "feature X is so
important, but I need a third-party package to have it" (something used a
lot to criticize JSF).
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [jira] Commented: (TAP5-1421) Create a standard way to track
messages to be presented to the user
Posted by Josh Canfield <jo...@gmail.com>.
> Alternately, perhaps we need to resuscitate the idea of a standard
> library (or libraries) beyond core.
My gut tells me to pull as much of the system apart into independent
modules as possible. Smaller is better, easier to understand, easier
to test.
Josh
On Wed, Jan 19, 2011 at 4:41 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> I think there's a larger discussion to be had about "what belongs in core".
>
> I think the original goal was "only things people couldn't live
> without" (Form, TextField, validations) and then grew from there:
>
> - Mega-components: BeanEditor, Grid
> - Client-side validations
> - Ajax components and mixins
>
> I really think core has evolved to be "things most projects can use
> as-is", or something to that effect. In fact, having a canonical way
> for services to record alerts to be presented to users would, itself,
> be a big bonus.
>
> I think it may have been premature at one time to include these
> things, but I think T5 now has a few years of real world experience to
> guide this ... including the projects I'm working on.
>
> So basically, I'm saying that I've found a specific use for this
> functionality and feel it can be generalized to most applications, and
> therefore it belongs. So we're going after "what makes people happy"
> rather than "pure".
>
> Alternately, perhaps we need to resuscitate the idea of a standard
> library (or libraries) beyond core. In T4, the library was a bit of a
> dumping ground for undocumented, untested code that people grew to
> depend on anyway.
>
> Perhaps this kind of thing belongs in TapX and we need to promote use
> of TapX more strongly. It originally started to fill needs caused by
> licensing issues, or desirable out-of-release-cycle changes (i.e., a
> standard library to patch prototype up to a more recent version).
>
> On Wed, Jan 19, 2011 at 2:35 PM, Andreas Andreou <an...@di.uoa.gr> wrote:
>> Well, with tapestry's extensibility it's not always straightforward
>> where such code better belongs to... Is there some guideline you're using
>> to decide?
>> Cause on the other hand, this SSO & service you're talking about would
>> also probably work with T5.2... that would imply that it'd better live outside
>> core, wouldn't it?
>>
>>
>> On Wed, Jan 19, 2011 at 22:56, Howard Lewis Ship <hl...@gmail.com> wrote:
>>> Not certain; I think the base implementation of the SSO and service
>>> would suffice for most projects, and the component could be easily
>>> augmented with CSS or replaced entirely.
>>>
>>> On Wed, Jan 19, 2011 at 12:51 PM, Andreas Andreou (JIRA)
>>> <ji...@apache.org> wrote:
>>>>
>>>> [ https://issues.apache.org/jira/browse/TAP5-1421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983883#action_12983883 ]
>>>>
>>>> Andreas Andreou commented on TAP5-1421:
>>>> ---------------------------------------
>>>>
>>>> Isn't it best to keep something like this out of the core?
>>>>
>>>>> Create a standard way to track messages to be presented to the user
>>>>> -------------------------------------------------------------------
>>>>>
>>>>> Key: TAP5-1421
>>>>> URL: https://issues.apache.org/jira/browse/TAP5-1421
>>>>> Project: Tapestry 5
>>>>> Issue Type: New Feature
>>>>> Components: tapestry-core
>>>>> Reporter: Howard M. Lewis Ship
>>>>> Priority: Minor
>>>>>
>>>>> For a client, I've created a GlobalAlerts SSO, along with a GlobalAlertsManager service, an Alerts component, even JavaScript client-side support for adding and clearing alerts. I'd like to generalize this code a bit ... currently Alerts messages are limited to strings (fully renderable would be better).
>>>>
>>>> --
>>>> This message is automatically generated by JIRA.
>>>> -
>>>> You can reply to this email to add a comment to the issue online.
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Howard M. Lewis Ship
>>>
>>> Creator of Apache Tapestry
>>>
>>> The source for Tapestry training, mentoring and support. Contact me to
>>> learn how I can get you up and productive in Tapestry fast!
>>>
>>> (971) 678-5210
>>> http://howardlewisship.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Andreas Andreou - andyhot@apache.org - http://blog.andyhot.gr
>> Tapestry PMC / Tacos developer
>> Open Source / JEE Consulting
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [jira] Commented: (TAP5-1421) Create a standard way to track
messages to be presented to the user
Posted by Howard Lewis Ship <hl...@gmail.com>.
I think there's a larger discussion to be had about "what belongs in core".
I think the original goal was "only things people couldn't live
without" (Form, TextField, validations) and then grew from there:
- Mega-components: BeanEditor, Grid
- Client-side validations
- Ajax components and mixins
I really think core has evolved to be "things most projects can use
as-is", or something to that effect. In fact, having a canonical way
for services to record alerts to be presented to users would, itself,
be a big bonus.
I think it may have been premature at one time to include these
things, but I think T5 now has a few years of real world experience to
guide this ... including the projects I'm working on.
So basically, I'm saying that I've found a specific use for this
functionality and feel it can be generalized to most applications, and
therefore it belongs. So we're going after "what makes people happy"
rather than "pure".
Alternately, perhaps we need to resuscitate the idea of a standard
library (or libraries) beyond core. In T4, the library was a bit of a
dumping ground for undocumented, untested code that people grew to
depend on anyway.
Perhaps this kind of thing belongs in TapX and we need to promote use
of TapX more strongly. It originally started to fill needs caused by
licensing issues, or desirable out-of-release-cycle changes (i.e., a
standard library to patch prototype up to a more recent version).
On Wed, Jan 19, 2011 at 2:35 PM, Andreas Andreou <an...@di.uoa.gr> wrote:
> Well, with tapestry's extensibility it's not always straightforward
> where such code better belongs to... Is there some guideline you're using
> to decide?
> Cause on the other hand, this SSO & service you're talking about would
> also probably work with T5.2... that would imply that it'd better live outside
> core, wouldn't it?
>
>
> On Wed, Jan 19, 2011 at 22:56, Howard Lewis Ship <hl...@gmail.com> wrote:
>> Not certain; I think the base implementation of the SSO and service
>> would suffice for most projects, and the component could be easily
>> augmented with CSS or replaced entirely.
>>
>> On Wed, Jan 19, 2011 at 12:51 PM, Andreas Andreou (JIRA)
>> <ji...@apache.org> wrote:
>>>
>>> [ https://issues.apache.org/jira/browse/TAP5-1421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983883#action_12983883 ]
>>>
>>> Andreas Andreou commented on TAP5-1421:
>>> ---------------------------------------
>>>
>>> Isn't it best to keep something like this out of the core?
>>>
>>>> Create a standard way to track messages to be presented to the user
>>>> -------------------------------------------------------------------
>>>>
>>>> Key: TAP5-1421
>>>> URL: https://issues.apache.org/jira/browse/TAP5-1421
>>>> Project: Tapestry 5
>>>> Issue Type: New Feature
>>>> Components: tapestry-core
>>>> Reporter: Howard M. Lewis Ship
>>>> Priority: Minor
>>>>
>>>> For a client, I've created a GlobalAlerts SSO, along with a GlobalAlertsManager service, an Alerts component, even JavaScript client-side support for adding and clearing alerts. I'd like to generalize this code a bit ... currently Alerts messages are limited to strings (fully renderable would be better).
>>>
>>> --
>>> This message is automatically generated by JIRA.
>>> -
>>> You can reply to this email to add a comment to the issue online.
>>>
>>>
>>
>>
>>
>> --
>> Howard M. Lewis Ship
>>
>> Creator of Apache Tapestry
>>
>> The source for Tapestry training, mentoring and support. Contact me to
>> learn how I can get you up and productive in Tapestry fast!
>>
>> (971) 678-5210
>> http://howardlewisship.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>
>
> --
> Andreas Andreou - andyhot@apache.org - http://blog.andyhot.gr
> Tapestry PMC / Tacos developer
> Open Source / JEE Consulting
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [jira] Commented: (TAP5-1421) Create a standard way to track
messages to be presented to the user
Posted by Andreas Andreou <an...@di.uoa.gr>.
Well, with tapestry's extensibility it's not always straightforward
where such code better belongs to... Is there some guideline you're using
to decide?
Cause on the other hand, this SSO & service you're talking about would
also probably work with T5.2... that would imply that it'd better live outside
core, wouldn't it?
On Wed, Jan 19, 2011 at 22:56, Howard Lewis Ship <hl...@gmail.com> wrote:
> Not certain; I think the base implementation of the SSO and service
> would suffice for most projects, and the component could be easily
> augmented with CSS or replaced entirely.
>
> On Wed, Jan 19, 2011 at 12:51 PM, Andreas Andreou (JIRA)
> <ji...@apache.org> wrote:
>>
>> [ https://issues.apache.org/jira/browse/TAP5-1421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983883#action_12983883 ]
>>
>> Andreas Andreou commented on TAP5-1421:
>> ---------------------------------------
>>
>> Isn't it best to keep something like this out of the core?
>>
>>> Create a standard way to track messages to be presented to the user
>>> -------------------------------------------------------------------
>>>
>>> Key: TAP5-1421
>>> URL: https://issues.apache.org/jira/browse/TAP5-1421
>>> Project: Tapestry 5
>>> Issue Type: New Feature
>>> Components: tapestry-core
>>> Reporter: Howard M. Lewis Ship
>>> Priority: Minor
>>>
>>> For a client, I've created a GlobalAlerts SSO, along with a GlobalAlertsManager service, an Alerts component, even JavaScript client-side support for adding and clearing alerts. I'd like to generalize this code a bit ... currently Alerts messages are limited to strings (fully renderable would be better).
>>
>> --
>> This message is automatically generated by JIRA.
>> -
>> You can reply to this email to add a comment to the issue online.
>>
>>
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Andreas Andreou - andyhot@apache.org - http://blog.andyhot.gr
Tapestry PMC / Tacos developer
Open Source / JEE Consulting
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [jira] Commented: (TAP5-1421) Create a standard way to track
messages to be presented to the user
Posted by Howard Lewis Ship <hl...@gmail.com>.
Not certain; I think the base implementation of the SSO and service
would suffice for most projects, and the component could be easily
augmented with CSS or replaced entirely.
On Wed, Jan 19, 2011 at 12:51 PM, Andreas Andreou (JIRA)
<ji...@apache.org> wrote:
>
> [ https://issues.apache.org/jira/browse/TAP5-1421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983883#action_12983883 ]
>
> Andreas Andreou commented on TAP5-1421:
> ---------------------------------------
>
> Isn't it best to keep something like this out of the core?
>
>> Create a standard way to track messages to be presented to the user
>> -------------------------------------------------------------------
>>
>> Key: TAP5-1421
>> URL: https://issues.apache.org/jira/browse/TAP5-1421
>> Project: Tapestry 5
>> Issue Type: New Feature
>> Components: tapestry-core
>> Reporter: Howard M. Lewis Ship
>> Priority: Minor
>>
>> For a client, I've created a GlobalAlerts SSO, along with a GlobalAlertsManager service, an Alerts component, even JavaScript client-side support for adding and clearing alerts. I'd like to generalize this code a bit ... currently Alerts messages are limited to strings (fully renderable would be better).
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org