anonymous wrote :
| So how about creating s:dataTable which extends h:dataTable and adds support for
| 1) Exporting to CSV,XML,Excel,PDF
| 2) Sorting
| 3) Paging
Well, this is definitly not the way I would go. (As a matter of fact tomahawk has done some of the stuff but last time I looked at it it was chaotic).
What I would wish is a tag lib which really produces genuine excel files - including formulas, cell types, number formats. It would be ideal if one could use an original excel file as a "template". Then one would add pivot tables and nice little graphs to the tamplate, the user could specify some filters and aggragation levels and then the pivot data would be copied to the excel file.
This would make a LOT of controllers very, very happy.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4023979#4023979
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4023979
Yes, execution of nodes should occur in a context. For that a jBPM context is used. It does not mean it has to be the identical, same context. That is why I said you have to hold on to a tokenid or processid to use that to get to the token/process when opening a new context. Look at the examples, testcases etc...
And yes, openening a new context in a new thread should scale (at least I hope so).... disabeling real persistency is simple by using an in-memory hsqld database and deleting the processinstance once it completes. If you do use a database, tuning of indexes etc... should indeed be done. jBPM only delivers minimal tuning..
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4023976#4023976
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4023976