I'm away on vacations so i didn't commit any code to apache svn.
But you can take a look of what's involved at
https://github.com/andyhot/tapestry5/commits/trunk
On Tue, Aug 23, 2011 at 13:44, Denis Stepanov wrote:
> I would like to have a zone param support for Chechbox and RadioGroup in 5.3.
>
I have implemented null check see:
https://issues.apache.org/jira/browse/TAP5-1615
can be used with propertyChain expressions: "prop?", "prop.a.b?.c?",
"method()?".
Denis
Gavin,
If I understand correctly, the modification of WTP's source code
directory is what causes this incompatibility. is that right? Is there
any hope that alternatives can be found that an alternative approach
can be found, maybe later? Switching to a different packaging of
Eclipse is quite burd
Yeah, you are right, this is the problem.
I am searching for another solution, hope that we can just install
TapestryTools in any version of Eclipse. In fact, i want to contact
with Eclipse WTP community, and contribute TapestryTools to Eclipse
WTP, make TapestryTools as default part of WTP, this
I don't really like hacks like extracting the value or calling process
submission also RadioGroup will not work because it doesn't have a client id.
Right now I would rather see small changes to add support for a zone param on
Checkbox and RadioGroup and refactoring after 5.3.
Denis
Aug 24, 20
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
On Wed, Aug 24, 2011 at 2:17 AM, Howard Lewis Ship wrote:
> It would probably be better to do this sooner, to ensure that the API
> I created is sufficient. I kind of winged it.
Would this be part of 5.3 ? ... I guess If that has to go in I would
wait for 5.4 release cycle...
Cheers
--
Massim
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
This is quite uncritical and can be part of 5.3.
On Wed, Aug 24, 2011 at 3:31 PM, Massimo Lusetti wrote:
> On Wed, Aug 24, 2011 at 2:17 AM, Howard Lewis Ship
> wrote:
>
> > It would probably be better to do this sooner, to ensure that the API
> > I created is sufficient. I kind of winged it.
>
On Wed, Aug 24, 2011 at 3:38 PM, Igor Drobiazko
wrote:
> This is quite uncritical and can be part of 5.3.
Even If that is not critical I would like to see the betas as a
code-freeze state of the tree... Just fixing bugs would be allowed.
I would like tapestry to have a policy in this regards...
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
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
As I wrote before, "!" doesn't do what I want, object needs to be converted to
a boolean first:
- null is converted to false
- unknown not null is converted to a string by calling toString metod and then
string is converted to a boolean
ToString method is usually implemented for debug purposes
On Wed, 24 Aug 2011 10:52:29 -0300, Denis Stepanov
wrote:
As I wrote before, "!" doesn't do what I want, object needs to be
converted to a boolean first:
- null is converted to false
- unknown not null is converted to a string by calling toString metod
and then string is converted to a b
Denis,
"X doesn't do what I want" is not a strong argument. In order to convince
someone to apply the patch, you need to make more efforts to describe you
issue. After reading all of your mails I'm still not sure what is the issue
with existing syntax. Please explain exactly your use case. As alwa
> "X doesn't do what I want" is not a strong argument. In order to convince
> someone to apply the patch, you need to make more efforts to describe you
> issue. After reading all of your mails I'm still not sure what is the issue
> with existing syntax. Please explain exactly your use case. As alwa
Just contribute your own coercion from Object -> Boolean.
On 24.08.2011 16:23, Denis Stepanov wrote:
>> "X doesn't do what I want" is not a strong argument. In order to convince
>> someone to apply the patch, you need to make more efforts to describe you
>> issue. After reading all of your mails I
Or do something like user?.address?.property
Uli
On 24.08.2011 16:38, Ulrich Stärk wrote:
> Just contribute your own coercion from Object -> Boolean.
>
> On 24.08.2011 16:23, Denis Stepanov wrote:
>>> "X doesn't do what I want" is not a strong argument. In order to convince
>>> someone to apply t
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
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
> Or do something like user?.address?.property
Would it be better to use just "user?.address?" without contributing coercion
for every object in a project? :)
We already have ifNotNull component I'm just trying to make Tapestry better :)
Text search revealed that we have 99 matches of
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
I am having the same kind of issues. +1.
On Aug 24, 2011, at 11:54 AM, Denis Stepanov wrote:
>> Or do something like user?.address?.property
>
>
> Would it be better to use just "user?.address?" without contributing coercion
> for every object in a project? :)
>
> We already have ifNotNul
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
If it still does not work for you, may be i have to record my screen
as a video, and then send it to you :-(
在 2011年8月25日 上午12:33，Gavin Lei 写道：
> Hi Igor,
>
> It seems that there is something wrong in your plugins list, not match
> with mine, attach files are the two required plugins (Gmail can o
> The issue is how to implement a null check logic in tml. Lets say we have
an object User and an Address, now if > address is not null I want to
display something different.
> If I use:
> or
So Tapestry already does what you want (checks for null) and it works. This
isn't a bug. What you real
> Is there any reason for Tapestry-IoC or Tapestry-core themselves not
> providing a direct Object -> Boolean coercion?
There is, let say "address" is a Boolean then you can't check for null, because
if it is null it will return false and if it isn't could be false too.
It will not work for defa
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
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
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,
> There is, let say "address" is a Boolean
Boolean -> Boolean is a nonsense coercion, the typecoercer actually
checks if the type is assignable from the source type and returns the
input unchanged.
These:
Long --> Boolean
String --> Boolean
Already exist. Since they are a better match than Objec
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
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
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
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
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
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
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
> Definitely. I'd rather add the Object -> Boolean and appropriate other
> coercions instead of adding a feature to the property expressions.
>
> I'm adding them to my personal project now. I'll be happy to add them
> to the framework once the dust of this thread settles :)
I'm afraid it will bre
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
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 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?
+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
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
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
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
-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
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:
>
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
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
I know this is a ridiculous optimization, but if instead of
StringBuffer you just use the + operator the compiler can put the
whole tag into one memory location instead of storing it in chunks.
final String tag = "\n\n" +
" __ __ \n" +
"/_ __/__
51 matches
Mail list logo
