Navigation trail: Turbine - Turbine2 - WishList
Turbine Wish List
If there are things that you would like to see changed or added to Turbine, here is the place to talk about it. Please sign your comments and/or suggestions. If you would like to cast a vote in favor of some of these requests, sign you name with a +1 after the discussion.
Note: the +1 is not to indicate a committer vote. It is to express your interest in the enhancement. The best way to REALLY cast you vote is to supply a patch ;-)
Have an OR Mapping Tool independent Turbine
In other words, let's have a Torque independant Turbine. -Check out the HibernateService... Hibernate is a very viable replacement. Also some work going on with OJB.
-Rodrigo Reyes
Intake: Database validations for a field
I would like to be able to have a field validated using a database lookup. This would be in addition to the normal validation rules.
== Intake: Wishlist from bug bugzilla== {{{ 1/
- Did You thing about extending intake.xml file with general rules like
<rule name="validation" type="custom" classname="my_class"> error text </rule> Which will make very large freedom to add new developer designed validation rules. 2/ Did You think about lokalizing error messages in intake.xml file. 3/ One more thing. In my project intake.xml file is too long. I have more than }}}
100 pages and about 60 forms. Manipulation in this file is very ugly. Do You think about make some changes in this behevior like we can put files with intake structure in one directory like actions, or screens and we can separate this files from each other.
From bug http://issues.apache.org/bugzilla/show_bug.cgi?id=8159
Intake: Group level validation
You should be able to validate relationships between fields within the same group. For example, I would like to validate that startDate > endDate where both fields are dates in the same group. This would require a group level isValid flag and a group level errorMessage.
Related messages on the turbine-dev list:
Intake: Javascript generation
Form field validation should ideally be done on the client side. It should also be done on the server side in case javascript is not available or is disabled on the client's browser. In order to prevent having to maintain one set of validation rules in Intake and another in javascript, I think that Intake should be abloe to generate javascript to perform form validation based upon the rules that are defined in intake.xml.
This would obviously preclude being able to generate validation rules that are only possible on the server such as database lookups. Generating most of the JS code for the client side validation is better than none at all!
Related messages on the turbine-dev list:
+1 - Why add to server-side compute load when unnecessary? Let the client do it! Extending Intake to generate js for validation would move Intake up the food chain as a powerful tool for form validation. -- jdiggans
In actual fact, Javascript validation is a convenience to users only, you still need to validate on the server to ensure someone isn't mucking about with the client or the data stream. This being the case, providing js validation will only add to the server side load. That said, I'm all for improving the user experience. -- ScottEade 2003-01-20
Getting Rundata by using a static method
e. g. Turbine.getRunData() would be great
--Anonymous
Intake: Documentation
- The service document should be rewritten to without examples from Scarab. This seems to be confusing for new users.
- A quick reference for the fields, validators, and rules should be developed.
Turbine Exception Handling
The way the Turbine 3 servlet passes Exceptions to the handleException method of a configured ExceptionHandler? would be useful for Turbine 2. Currently the handleException method is implemented in the Turbine 2 servlet, but it would be better to allow a custom implementation.
This was originally posted by Rodney Schneider on the turbine-dev list
[[/PageLayout|Embedded layouts on Velocity templates]]
More robust multi-part message handling
Implement more robust multipart message handling (org/apache/turbine/util/mail)
(This item was copied from http://jakarta.apache.org/turbine/turbine-2/todo.html)
Cocoon 2 Implementation
Well thought out (and executed) Cocoon 2 Implementation
(This item was copied from http://jakarta.apache.org/turbine/turbine-2/todo.html)
Email Host using javax.mail.Session from JNDI
At this point Turbine is pretty focussed on getting it's configuration from a TR.props. For instance, what mail host to use is dependent on what is set as smtp.host.
I am finding this requires lots of funky build scripts, because my smtp.host is different in development from production. And, regular admin types can't easily edit tr.props files.
Therefore we are switching to using JNDI for as many of our settings that change as possible. I would like to change the VelocityEmail to take in a jndi javax.mail.session to use instead. This would require a change to the tr.props as well to specify mail.session=jndi/props or something of that nature?
What do you all think? Towards this end, I submitted a patch to commons-email ( http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16859) a couple weeks ago to allow it to take a javax.mail.Session as well as a mailHost. However that patch hasn't been dealt with.
If this sounds like a good enhancement, then if someone who is also a committer on commons could apply my patch, and give me the go ahead, I'll make the changes to tr.props to make the mail host a properties or jndi setting.
sincerely, EricPugh
Be able to use commons-validator instead of Intake
I have a turbine app that works with DBforms. DbForms can use the commons-validator code. So, instead of two methods of validating code, I would like to just use commons-validator. I also find Intake very difficult to use.