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
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
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 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
S
There is no way its reasonable to for a developer to figured this one out with
help:
think things like this can be vastly improved by an API.
Example:
@Match("AssetPathConverter")
@SuppressWarnings("unchecked")
public void adviseJsPathMethod(MethodAdviceReceiver receiver)
t
On Wed, 24 Aug 2011 15:39:43 -0300, Lenny Primak
wrote:
I like that too, but not necessarily enough. For example, contributing
a service isn't only a matter of finding the right service class,
but also there is a lot of code involved that it's not reasonable for
anyone new to know how to
+1
It would be nice with a FAQ- /cookbook-like page covering the most common
tasks. - With the possibility to add best-practice comments, mention
differences between versions etc.
--
Chris
On Wed, Aug 24, 2011 at 8:39 PM, Thiago H. de Paula Figueiredo <
thiag...@gmail.com> wrote:
> On Wed, 24
I have no issue with fixing it in the documentation either,
but I do believe there are too many permutations to make it a workable fix.
This is the issue with the reverse lookup as well. There are too many things
that a developer 'might'
do to make it useful, but I may be wrong here, who knows?
On Wed, 24 Aug 2011 15:26:11 -0300, Lenny Primak
wrote:
Thiago, I don't think you are understanding the gist of my comments.
I disagree. :) I just think this should be solved by documentation, not
code, as Robert has just said.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache T
I like that too, but not necessarily enough. For example, contributing a
service isn't only a matter of finding the right service class,
but also there is a lot of code involved that it's not reasonable for anyone
new to know how to create that piece of code,
i.e. code that invokes class transfo
Sure... in fact, it would be a fairly simple matter to create such a service
and interface. Define your interface with whatever methods you want, then your
implementation class injects the registry and gets the objects from the
registry, or else injects the objects directly and returns them.
I
On Wed, 24 Aug 2011 15:09:07 -0300, Lenny Primak
wrote:
For example:
core.getServiceFiter().contribute(myTimingFilter)
Is this asking to add contributions after the service registry is
instantiated? If yes, I don't think this will ever be implemented because
this would change too much h
I am not, nor do I want to be in the business of framework development /
support.
I am just trying to make suggestions based on my experience to make the
framework easier to use by others.
I wasn't even the one to bring up the TapestryCoreServices idea, I just like it
and it suits what I would l
Hi!
I appreciate the effort required to get to know Tapestry. It's true
that being on the project for a long time can make it hard to see the
pain of the learning curve.
Having a single point of entry for every object you might want to use
seems a little out there though. If you like this design
Hi,
Personally I like the "documentation solution" better than the "explicit
code" version you posted.
I think you could create your own version of what you suggest (without too
much hassle) and make that public to your team/others that prefer that
style. My guess is that its not necessarily some
On Wed, 24 Aug 2011 12:25:16 -0300, Lenny Primak
wrote:
Thiago,
Hi!
Every product that I know of other than tapestry has a well defined API.
I am not knocking tapestry, it is a great product, but it's the only one
that I know of that does not have a well defined API but is a collection
For example:
core.getServiceFiter().contribute(myTimingFilter)
core.getComponentResources().xxx();
core.getApplicationDefaults.set();
core.getJavaScriptSupport().importLibrary();
core.getFormSupport().xxx();
Basically, an interface that makes up 'core' services.
Obviously, not complete but I think
Thiago,
Every product that I know of other than tapestry has a well defined API.
I am not knocking tapestry, it is a great product, but it's the only one that I
know of that does not have a well defined API but is a collection of
by-convention like injection points, static methods to override,
On Wed, 24 Aug 2011 14:49:36 -0300, Lenny Primak
wrote:
I think the key here at least for me is that there is one entry point
for most common things.
Then there's a problem: defining what is the most common things.
@Inject is nice but tapestry also has @Contribute and other inject
varia
I think the key here at least for me is that there is one entry point for most
common things.
The fact that the IDE takes you there and give you javadocs as you explore the
services is an added bonus. Just makes things easier and more obvious. @Inject
is nice but tapestry also has @Contribute a
Hi,
On one hand I can see that access to all services in ones IDE is a nice
thought, on the other hand I fail to see how it would help you to pick the
service you need; if you don't know what you are looking for...
Going directly into the javadocs and checking all classes that sound
relevant may
I really like the TapestryCoreServices idea. Inject one object and have access
to all the core services.
This approach would make a lot more things more obvious in tapestry.
I think tapestry is a little lacking when it comes to the obviousness of doing
certain things.
On Aug 24, 2011, at
On Wed, 24 Aug 2011 10:50:54 -0300, Chris Poulsen
wrote:
Hi,
Can't you just inject it?
@Inject
private ServletContext servletContext;
I like this idea, as we can already inject HttpServletRequest and
HttpServletResponse. :)
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry
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 c
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 man
Hi,
Can't you just inject it?
@Inject
private ServletContext servletContext;
--
Chris
On Wed, Aug 24, 2011 at 3:25 PM, Barry Books 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 i
On Wed, Aug 24, 2011 at 3:25 PM, Barry Books 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 documentat
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
29 matches
Mail list logo
