T5: Grid component, reorder and empty source
hi, I am using the grid component to present the result from a search. When the data source is empty, table t:type=grid pagerPosition=both source=persons / returns There is no data to display. as expected. but when I try to use the reorder parameter, table t:type=grid pagerPosition=both source=persons reorder=firstName / an application exception occur: ...grid: xxx -- no source to determine list type from Is it supposed to be a non-empty datasource when using parameters like reorder or remove? (I am now reordering by get'ers and remove with @NonVisual in my domain-model. Version is 5.0.6.) thanks, Arve Klev
T5 : How to use checkbox inside of the grid components
hi... i have list of daya displayed by grid component now i want to add checkbox for each row could anyone give me an example how to do it ? thnx dwi ardi irawan http://dwiardiirawan.blogspot.com Dwi Ardi Irawan ~ ...and the story goes ~ Blog : http://dwiardiirawan.blogspot.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Feedback wanted on IoC documentation
Hi Thanks again for this effort of documentation. I have a question about dependency injection between services. We can inject a service thanks to the @Inject annotation in a page component. I find this feature pretty handy. But (correct me if I'm wrong but I think I'm not because I test it) we can't @Inject a service in a sercice. Instead we must provide the service to the other service through its constructor. Why did you make this choice ? I would find useful as well to inject a service in a service with the same annotation ? Michael Howard Lewis Ship a écrit : I've been working on new documentation about Tapestry IoC (similar stuff will be coming for Tapestry core): Overview: http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/overview.html Cookbook: http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/cookbook/index.html Feedback is encouraged! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feedback wanted on IoC documentation
I was just wondering the opposite - why not constructor injection for pages/components? Martin On Sat, 10 Nov 2007 21:43:10 +0100, Michael Courcy [EMAIL PROTECTED] wrote: Hi Thanks again for this effort of documentation. I have a question about dependency injection between services. We can inject a service thanks to the @Inject annotation in a page component. I find this feature pretty handy. But (correct me if I'm wrong but I think I'm not because I test it) we can't @Inject a service in a sercice. Instead we must provide the service to the other service through its constructor. Why did you make this choice ? I would find useful as well to inject a service in a service with the same annotation ? Michael Howard Lewis Ship a écrit : I've been working on new documentation about Tapestry IoC (similar stuff will be coming for Tapestry core): Overview: http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/overview.html Cookbook: http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/cookbook/index.html Feedback is encouraged! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
T5: Grid component calls prepare() and getRowValue() with incorrect values
All,
I just entered a JIRA:
https://issues.apache.org/jira/browse/TAPESTRY-1901
I'm posting the details here in case anyone monitoring the list has the
same issue. I believe there's a workaround.
I have a grid defined with rowsPerPage = 2. When there are 3 elements in
the GridDataSource, the user clicks the 2 link to display page 2. (So
that there is only one element displaying). The user clicks an action
link that has the following event handler defined:
public ListAccount onActionFromDel( Integer prmRId ) {
_DAO.delByRId(prmRId);
return( _listAccount );
}
(ListAccount is the current page class).
As the Grid attempts to re-render itself, it calls getAvailableRows() on
the GridDataSource, and getAvailableRows() correctly returns 2.
The Grid should automatically go to page 1 since there are only 2 rows
available and rowsPerPage is set to 2. However, instead, the Grid calls
prepare() with firstResult = 2 and lastResult = 1. After this, the Grid
calls getRowValue() with a negative value.
Note that the problem goes away if I add a line to the event handler:
public ListAccount onActionFromDel( Integer prmRId ) {
_DAO.delByRId(prmRId);
_listAccount._actList.setCurrentPage( 1 ); -- this line
solves the problem
return( _listAccount );
}
But I don't believe this should be necessary.
Thanks,
Andy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feedback wanted on IoC documentation
Services are loaded by the normal class loader without any special trickery. We create classes (proxies and such), but don't modify existing classes for Tapestry IoC. This is necessary to ensure that services code inter-operates properly with all kinds of third party, legacy and other code that is far, far beyond the scope of Tapestry IoC. To encourage service implementations to properly store service depenencies as final instance variables, such dependencies are passed only into the constructor. So for services, injection is assumed, for the constructor parameters (as if an @Inject annotation was present). Now for components, it's a different story. The component classes are very specific to Tapestry, not intended for reuse elsewhere, and are modified at runtime to work properly and efficiently within the constraints of Tapestry's multi-threaded runtime environment. Tapestry components are quite a bit different from service, in terms of lifecycle, and in terms of the what can be injected (all sorts of resources besides services) and in the fact that they q On Nov 10, 2007 12:59 PM, Martin Strand [EMAIL PROTECTED] wrote: I was just wondering the opposite - why not constructor injection for pages/components? Martin On Sat, 10 Nov 2007 21:43:10 +0100, Michael Courcy [EMAIL PROTECTED] wrote: Hi Thanks again for this effort of documentation. I have a question about dependency injection between services. We can inject a service thanks to the @Inject annotation in a page component. I find this feature pretty handy. But (correct me if I'm wrong but I think I'm not because I test it) we can't @Inject a service in a sercice. Instead we must provide the service to the other service through its constructor. Why did you make this choice ? I would find useful as well to inject a service in a service with the same annotation ? Michael Howard Lewis Ship a écrit : I've been working on new documentation about Tapestry IoC (similar stuff will be coming for Tapestry core): Overview: http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/overview.html Cookbook: http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/cookbook/index.html Feedback is encouraged! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Howard M. Lewis Ship Partner and Senior Architect at Feature50 Creator Apache Tapestry and Apache HiveMind - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feedback wanted on IoC documentation
Services are loaded by the normal class loader without any special
trickery. We create classes (proxies and such), but don't modify
existing classes for Tapestry IoC. This is necessary to ensure that
services code inter-operates properly with all kinds of third party,
legacy and other code that is far, far beyond the scope of Tapestry
IoC.
To encourage service implementations to properly store service
depenencies as final instance variables, such dependencies are passed
only into the constructor.
So for services, injection is assumed, for the constructor parameters
(as if an @Inject annotation was present).
Now for components, it's a different story. The component classes are
very specific to Tapestry, not intended for reuse elsewhere, and are
modified at runtime to work properly and efficiently within the
constraints of Tapestry's multi-threaded runtime environment.
Tapestry components are quite a bit different from service, in terms
of lifecycle, and in terms of the what can be injected (all sorts of
resources besides services) and in the fact that they quite often have
considerable (if largely temporary)
internal state, while services most often have no internal state at all.
Constructor injection is insufficient for components, because Tapestry
needs to really know about the individual fields. For example, if
you:
@Inject
private MyService _service;
... and then in some code:
void onActionFromNotAGoodIdea()
{
_service = new MyOtherImpl();
}
You'll actually get a runtime error explaining that the field is read only.
So field injection is both necessary and requires far less typing ...
you don't have to write a constructor and assigning all the fields
from it. On the other hand, the fields aren't final (though they often
act final).
The real downside is that you have a similar concept, injection, with
two very different expressions.
It would be interesting if Tapestry IoC could support injection on
fields, and backtrack from the field to the constructor parameter.
It might also be interesting if components could define a constructor
and Tapestry could work forwards from the parameter annotations
forwards to the fields. I think both approaches would require a large
amount of effort and may not actually add any value.
Certainly in the short term, people would be much happier if we got
the Ajax support going.
Of course, I'm writing this on my PC while I get Leopard installed
onto my Mac (my main development machine).
On Nov 10, 2007 12:43 PM, Michael Courcy [EMAIL PROTECTED] wrote:
Hi
Thanks again for this effort of documentation.
I have a question about dependency injection between services.
We can inject a service thanks to the @Inject annotation in a page
component.
I find this feature pretty handy.
But (correct me if I'm wrong but I think I'm not because I test it) we
can't @Inject a service in a sercice.
Instead we must provide the service to the other service through its
constructor.
Why did you make this choice ?
I would find useful as well to inject a service in a service with the
same annotation ?
Michael
Howard Lewis Ship a écrit :
I've been working on new documentation about Tapestry IoC (similar
stuff will be coming for Tapestry core):
Overview:
http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/overview.html
Cookbook:
http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/cookbook/index.html
Feedback is encouraged!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Howard M. Lewis Ship
Partner and Senior Architect at Feature50
Creator Apache Tapestry and Apache HiveMind
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feedback wanted on IoC documentation
Thanks for taking the time to explain. I haven't looked closely into T5,
maybe constructor injection is impossible. I just don't understand why it
would be insufficient in this case. Or is it just that you prefer
annotated fields?
Your example:
Constructor injection is insufficient for components, because Tapestry
needs to really know about the individual fields. For example, if
you:
@Inject
private MyService _service;
... and then in some code:
void onActionFromNotAGoodIdea()
{
_service = new MyOtherImpl();
}
You'll actually get a runtime error explaining that the field is read
only.
But with constructor injection the fields could be final instead and that
code wouldn't even compile!
Perhaps it would be possible if only services could be injected this way?
Martin
On Sun, 11 Nov 2007 00:29:50 +0100, Howard Lewis Ship [EMAIL PROTECTED]
wrote:
Services are loaded by the normal class loader without any special
trickery. We create classes (proxies and such), but don't modify
existing classes for Tapestry IoC. This is necessary to ensure that
services code inter-operates properly with all kinds of third party,
legacy and other code that is far, far beyond the scope of Tapestry
IoC.
To encourage service implementations to properly store service
depenencies as final instance variables, such dependencies are passed
only into the constructor.
So for services, injection is assumed, for the constructor parameters
(as if an @Inject annotation was present).
Now for components, it's a different story. The component classes are
very specific to Tapestry, not intended for reuse elsewhere, and are
modified at runtime to work properly and efficiently within the
constraints of Tapestry's multi-threaded runtime environment.
Tapestry components are quite a bit different from service, in terms
of lifecycle, and in terms of the what can be injected (all sorts of
resources besides services) and in the fact that they quite often have
considerable (if largely temporary)
internal state, while services most often have no internal state at all.
Constructor injection is insufficient for components, because Tapestry
needs to really know about the individual fields. For example, if
you:
@Inject
private MyService _service;
... and then in some code:
void onActionFromNotAGoodIdea()
{
_service = new MyOtherImpl();
}
You'll actually get a runtime error explaining that the field is read
only.
So field injection is both necessary and requires far less typing ...
you don't have to write a constructor and assigning all the fields
from it. On the other hand, the fields aren't final (though they often
act final).
The real downside is that you have a similar concept, injection, with
two very different expressions.
It would be interesting if Tapestry IoC could support injection on
fields, and backtrack from the field to the constructor parameter.
It might also be interesting if components could define a constructor
and Tapestry could work forwards from the parameter annotations
forwards to the fields. I think both approaches would require a large
amount of effort and may not actually add any value.
Certainly in the short term, people would be much happier if we got
the Ajax support going.
Of course, I'm writing this on my PC while I get Leopard installed
onto my Mac (my main development machine).
On Nov 10, 2007 12:43 PM, Michael Courcy [EMAIL PROTECTED]
wrote:
Hi
Thanks again for this effort of documentation.
I have a question about dependency injection between services.
We can inject a service thanks to the @Inject annotation in a page
component.
I find this feature pretty handy.
But (correct me if I'm wrong but I think I'm not because I test it) we
can't @Inject a service in a sercice.
Instead we must provide the service to the other service through its
constructor.
Why did you make this choice ?
I would find useful as well to inject a service in a service with the
same annotation ?
Michael
Howard Lewis Ship a écrit :
I've been working on new documentation about Tapestry IoC (similar
stuff will be coming for Tapestry core):
Overview:
http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/overview.html
Cookbook:
http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/cookbook/index.html
Feedback is encouraged!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feedback wanted on IoC documentation
Ok I think I have understood your explainations (actually I'm not pretty
sure)
The component is totally managed by tapestry and by injecting services
through @Inject annotation you get more control on its fields.
While in the other hand you encourage proper storage of service by
making injection only available through constructor.
Well, honestly I don't have enough experiences to assess that, it's
doing the job properly anyway, I was a bit curious that's all.
I agree on the fact that making those two ways dependencies injection
available in both context won't bring that much compare to the
expectation of the community : Ajax and the next tutorial on form ;-).
Thanks for your answer.
Michael
Howard Lewis Ship a écrit :
Services are loaded by the normal class loader without any special
trickery. We create classes (proxies and such), but don't modify
existing classes for Tapestry IoC. This is necessary to ensure that
services code inter-operates properly with all kinds of third party,
legacy and other code that is far, far beyond the scope of Tapestry
IoC.
To encourage service implementations to properly store service
depenencies as final instance variables, such dependencies are passed
only into the constructor.
So for services, injection is assumed, for the constructor parameters
(as if an @Inject annotation was present).
Now for components, it's a different story. The component classes are
very specific to Tapestry, not intended for reuse elsewhere, and are
modified at runtime to work properly and efficiently within the
constraints of Tapestry's multi-threaded runtime environment.
Tapestry components are quite a bit different from service, in terms
of lifecycle, and in terms of the what can be injected (all sorts of
resources besides services) and in the fact that they quite often have
considerable (if largely temporary)
internal state, while services most often have no internal state at all.
Constructor injection is insufficient for components, because Tapestry
needs to really know about the individual fields. For example, if
you:
@Inject
private MyService _service;
... and then in some code:
void onActionFromNotAGoodIdea()
{
_service = new MyOtherImpl();
}
You'll actually get a runtime error explaining that the field is read only.
So field injection is both necessary and requires far less typing ...
you don't have to write a constructor and assigning all the fields
from it. On the other hand, the fields aren't final (though they often
act final).
The real downside is that you have a similar concept, injection, with
two very different expressions.
It would be interesting if Tapestry IoC could support injection on
fields, and backtrack from the field to the constructor parameter.
It might also be interesting if components could define a constructor
and Tapestry could work forwards from the parameter annotations
forwards to the fields. I think both approaches would require a large
amount of effort and may not actually add any value.
Certainly in the short term, people would be much happier if we got
the Ajax support going.
Of course, I'm writing this on my PC while I get Leopard installed
onto my Mac (my main development machine).
On Nov 10, 2007 12:43 PM, Michael Courcy [EMAIL PROTECTED] wrote:
Hi
Thanks again for this effort of documentation.
I have a question about dependency injection between services.
We can inject a service thanks to the @Inject annotation in a page
component.
I find this feature pretty handy.
But (correct me if I'm wrong but I think I'm not because I test it) we
can't @Inject a service in a sercice.
Instead we must provide the service to the other service through its
constructor.
Why did you make this choice ?
I would find useful as well to inject a service in a service with the
same annotation ?
Michael
Howard Lewis Ship a écrit :
I've been working on new documentation about Tapestry IoC (similar
stuff will be coming for Tapestry core):
Overview:
http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/overview.html
Cookbook:
http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/cookbook/index.html
Feedback is encouraged!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feedback wanted on IoC documentation
Overall: Very good, if this stuff gets a little more fleshed out it will be a huge help in getting started with T5. I would suggest that on the last example in the overview (MonitorModule) you add a tiny bit of text explaining that the contribute method is part of Tapestry IoC's configuration conventions - after I read though the rest of the cookbook this made sense. Howard Lewis Ship wrote: I've been working on new documentation about Tapestry IoC (similar stuff will be coming for Tapestry core): Overview: http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/overview.html Cookbook: http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/cookbook/index.html Feedback is encouraged! -- Robert r. Sanders Chief Technologist iPOV (334) 821-5412 www.ipov.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
