You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Barry Books <tr...@gmail.com> on 2011/08/24 15:25:58 UTC
Would it be possible (or desirable) to add a TapestryCoreServices
Interface for 5.3 beta?
I just spent about 30 minutes looking for a way to get the
ServletContext. I knew it was available but I could not remember which
service provides it. So while I was searching I was thinking it might
be nice to have a set of Interfaces/Services that define all the
public services. For Tapestry core that might be TapestryCoreServices
and TapestryCoreRequestServices to differentiate between global
services and ones that are request specific. This would help with a
few things. One I could just say
@Inject
private TapestryCoreServices coreServices;
then just
coreServices.getApplicationGlobals().getServletContext()
This would cut down on the number of fields I need to create just to
call a few methods. Secondly I think would make it more obvious which
services are public and which are internal. I realize the package does
that but who looks at the package name? Lastly I think it would be
easier for new comers to learn what services are available. The last
one is not a complaint about the documentation but more a comment
about how useful code completion can be.
So in short the Interface would give you a starting point to all the
services available from a module. The naming convention could continue
such as TapestryIOCServices etc.
Thanks
Barry
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Would it be possible (or desirable) to add a
TapestryCoreServices Interface for 5.3 beta?
Posted by trsvax <tr...@gmail.com>.
I tried to steer clear of calling this a documentation "issue" in my post
because I while this seems like a documentation problem I don't think more
documentation is the answer because an Interface is really tied to the
compiler and documentation is not. So it really does two things
documentation cannot not do.
1. Provides a compiler enforced API to Taptestry.
2. Allows an IDE to perform code completion.
But at the same time it does provide quick access to the documentation via
IDE code completion.
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Would-it-be-possible-or-desirable-to-add-a-TapestryCoreServices-Interface-for-5-3-beta-tp4730424p4730728.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Would it be possible (or desirable) to add a TapestryCoreServices
Interface for 5.3 beta?
Posted by Massimo Lusetti <ml...@gmail.com>.
On Wed, Aug 24, 2011 at 3:25 PM, Barry Books <tr...@gmail.com> wrote:
> So in short the Interface would give you a starting point to all the
> services available from a module. The naming convention could continue
> such as TapestryIOCServices etc.
I'm split here but that seems you're trying to solve a documentation
"issue" (note the double quotes) with a code solution...
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: Would it be possible (or desirable) to add a TapestryCoreServices Interface for 5.3 beta?
Posted by Lenny Primak <lp...@hope.nyc.ny.us>.
I have been thinking about this as well. This is a general problem with dependency injection. When a.developer wants something, it's hard to search for it in the world of DI. it's much easier to have an API to do things. Right now there are hundreds of objects to inject, and each of them has many getter methods and indirections to get at the thing that a developer might want. Also there are hundreds of contribution and override points. Its next to impossible to find the right thing to do when coming from a new developer perspective. Even if you know what to inject or contribute, it's hard without the code examples.
It's partly a documentation problem but I think it's really hard to fix just in the docs since the are so many permutations of what a developer might do.
Thus, I think an API is a great idea.
On Aug 24, 2011, at 9:25 AM, Barry Books <tr...@gmail.com> wrote:
> I just spent about 30 minutes looking for a way to get the
> ServletContext. I knew it was available but I could not remember which
> service provides it. So while I was searching I was thinking it might
> be nice to have a set of Interfaces/Services that define all the
> public services. For Tapestry core that might be TapestryCoreServices
> and TapestryCoreRequestServices to differentiate between global
> services and ones that are request specific. This would help with a
> few things. One I could just say
>
> @Inject
> private TapestryCoreServices coreServices;
>
> then just
> coreServices.getApplicationGlobals().getServletContext()
>
> This would cut down on the number of fields I need to create just to
> call a few methods. Secondly I think would make it more obvious which
> services are public and which are internal. I realize the package does
> that but who looks at the package name? Lastly I think it would be
> easier for new comers to learn what services are available. The last
> one is not a complaint about the documentation but more a comment
> about how useful code completion can be.
>
> So in short the Interface would give you a starting point to all the
> services available from a module. The naming convention could continue
> such as TapestryIOCServices etc.
>
> Thanks
> Barry
>
> ---------------------------------------------------------------------
> 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: Would it be possible (or desirable) to add a TapestryCoreServices Interface for 5.3 beta?
Posted by Lenny Primak <lp...@hope.nyc.ny.us>.
Please do so. I will totally have my team use it!
On Aug 24, 2011, at 4:26 PM, trsvax wrote:
> While http://tapestry.apache.org/service-status.html is useful for debugging
> I don't think it's a good idea to use it as the list of services because
> there are internal ones as well as public ones listed and that's where the
> trouble starts.
>
> I do agree about having lots of code completions but what are you going to
> do? And why does java.awt.List keep showing up even though I've never picked
> it on purpose. But worst of all why are there 15 loggers and sl4j is always
> at the bottom. Coding is hard I think I'll go to lunch :)
>
> Interesting discussion. I'm not sure how well it would work either but I
> don't really see any downside. Perhaps I'll make one and put it on GitHub.
>
>
>
> --
> View this message in context: http://tapestry.1045711.n5.nabble.com/Would-it-be-possible-or-desirable-to-add-a-TapestryCoreServices-Interface-for-5-3-beta-tp4730424p4731782.html
> Sent from the Tapestry - Dev mailing list archive at Nabble.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: Would it be possible (or desirable) to add a
TapestryCoreServices Interface for 5.3 beta?
Posted by trsvax <tr...@gmail.com>.
While http://tapestry.apache.org/service-status.html is useful for debugging
I don't think it's a good idea to use it as the list of services because
there are internal ones as well as public ones listed and that's where the
trouble starts.
I do agree about having lots of code completions but what are you going to
do? And why does java.awt.List keep showing up even though I've never picked
it on purpose. But worst of all why are there 15 loggers and sl4j is always
at the bottom. Coding is hard I think I'll go to lunch :)
Interesting discussion. I'm not sure how well it would work either but I
don't really see any downside. Perhaps I'll make one and put it on GitHub.
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Would-it-be-possible-or-desirable-to-add-a-TapestryCoreServices-Interface-for-5-3-beta-tp4730424p4731782.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Would it be possible (or desirable) to add a TapestryCoreServices Interface for 5.3 beta?
Posted by Lenny Primak <lp...@hope.nyc.ny.us>.
You don't have to use it if you don't want to. I think the only negative here is the status quo.
It's indeed a powerful negative, but... perhaps status quo isn't always a good thing.
I can see this being a boon for new tapestry developers.
On Aug 24, 2011, at 3:26 PM, Igor Drobiazko wrote:
> -1
>
> Such a TapestryCoreServices goes against the fundamental ideas in Tapestry.
> The framework is assembled from a lot of small pieces. You inject only what
> you need and when you need.
>
> Did you know there is a page listing all the available services?
>
> http://tapestry.apache.org/service-status.html
>
> I strongly believe that TapestryCoreServices would not make your life
> easier. Just imagine how many methods you would see in the autocompletion
> box. I think more than 100. You will be lost. I remember the nightmare
> writing Java swing code where every class inherits plenty of methods from
> the super-classes.
>
>
> On Wed, Aug 24, 2011 at 3:25 PM, Barry Books <tr...@gmail.com> wrote:
>
>> I just spent about 30 minutes looking for a way to get the
>> ServletContext. I knew it was available but I could not remember which
>> service provides it. So while I was searching I was thinking it might
>> be nice to have a set of Interfaces/Services that define all the
>> public services. For Tapestry core that might be TapestryCoreServices
>> and TapestryCoreRequestServices to differentiate between global
>> services and ones that are request specific. This would help with a
>> few things. One I could just say
>>
>> @Inject
>> private TapestryCoreServices coreServices;
>>
>> then just
>> coreServices.getApplicationGlobals().getServletContext()
>>
>> This would cut down on the number of fields I need to create just to
>> call a few methods. Secondly I think would make it more obvious which
>> services are public and which are internal. I realize the package does
>> that but who looks at the package name? Lastly I think it would be
>> easier for new comers to learn what services are available. The last
>> one is not a complaint about the documentation but more a comment
>> about how useful code completion can be.
>>
>> So in short the Interface would give you a starting point to all the
>> services available from a module. The naming convention could continue
>> such as TapestryIOCServices etc.
>>
>> Thanks
>> Barry
>>
>> ---------------------------------------------------------------------
>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Would it be possible (or desirable) to add a TapestryCoreServices
Interface for 5.3 beta?
Posted by Igor Drobiazko <ig...@gmail.com>.
-1
Such a TapestryCoreServices goes against the fundamental ideas in Tapestry.
The framework is assembled from a lot of small pieces. You inject only what
you need and when you need.
Did you know there is a page listing all the available services?
http://tapestry.apache.org/service-status.html
I strongly believe that TapestryCoreServices would not make your life
easier. Just imagine how many methods you would see in the autocompletion
box. I think more than 100. You will be lost. I remember the nightmare
writing Java swing code where every class inherits plenty of methods from
the super-classes.
On Wed, Aug 24, 2011 at 3:25 PM, Barry Books <tr...@gmail.com> wrote:
> I just spent about 30 minutes looking for a way to get the
> ServletContext. I knew it was available but I could not remember which
> service provides it. So while I was searching I was thinking it might
> be nice to have a set of Interfaces/Services that define all the
> public services. For Tapestry core that might be TapestryCoreServices
> and TapestryCoreRequestServices to differentiate between global
> services and ones that are request specific. This would help with a
> few things. One I could just say
>
> @Inject
> private TapestryCoreServices coreServices;
>
> then just
> coreServices.getApplicationGlobals().getServletContext()
>
> This would cut down on the number of fields I need to create just to
> call a few methods. Secondly I think would make it more obvious which
> services are public and which are internal. I realize the package does
> that but who looks at the package name? Lastly I think it would be
> easier for new comers to learn what services are available. The last
> one is not a complaint about the documentation but more a comment
> about how useful code completion can be.
>
> So in short the Interface would give you a starting point to all the
> services available from a module. The naming convention could continue
> such as TapestryIOCServices etc.
>
> Thanks
> Barry
>
> ---------------------------------------------------------------------
> 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: Would it be possible (or desirable) to add a TapestryCoreServices
Interface for 5.3 beta?
Posted by Chris Poulsen <ma...@nesluop.dk>.
Hi,
Can't you just inject it?
@Inject
private ServletContext servletContext;
--
Chris
On Wed, Aug 24, 2011 at 3:25 PM, Barry Books <tr...@gmail.com> wrote:
> I just spent about 30 minutes looking for a way to get the
> ServletContext. I knew it was available but I could not remember which
> service provides it. So while I was searching I was thinking it might
> be nice to have a set of Interfaces/Services that define all the
> public services. For Tapestry core that might be TapestryCoreServices
> and TapestryCoreRequestServices to differentiate between global
> services and ones that are request specific. This would help with a
> few things. One I could just say
>
> @Inject
> private TapestryCoreServices coreServices;
>
> then just
> coreServices.getApplicationGlobals().getServletContext()
>
> This would cut down on the number of fields I need to create just to
> call a few methods. Secondly I think would make it more obvious which
> services are public and which are internal. I realize the package does
> that but who looks at the package name? Lastly I think it would be
> easier for new comers to learn what services are available. The last
> one is not a complaint about the documentation but more a comment
> about how useful code completion can be.
>
> So in short the Interface would give you a starting point to all the
> services available from a module. The naming convention could continue
> such as TapestryIOCServices etc.
>
> Thanks
> Barry
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
Re: Would it be possible (or desirable) to add a
TapestryCoreServices Interface for 5.3 beta?
Posted by trsvax <tr...@gmail.com>.
I was not envisioning anything very complicated just an Interface with all of
the non deprecated Interfaces in org.apache.tapestry5.services. I was not
looking for any new functionality.
To me code completion works much like reverse documentation. If I want a
ServletContext I would start typing
ServletContext context = core.
and go from there. Odds are I'd go down a few dead ends but I'd find the
right method pretty quickly (or give up and start using Google). Perhaps
it's just me but I would never start with the JavaDocs.
The positives are:
Certainty you are using the current public API (at least for the services).
Better IDE support
Perhaps:
Fewer field variables in pages/components. I can't count the number I've
times I've left off private.
Fewer arguments to Service constructors.
Personally I can't think of any negatives.
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Would-it-be-possible-or-desirable-to-add-a-TapestryCoreServices-Interface-for-5-3-beta-tp4730424p4731601.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org