[prev in list] [next in list] [prev in thread] [next in thread] 

List:       turbine-dev
Subject:    Re: Intake
From:       "Henning P. Schmiedehausen" <hps () intermeta ! de>
Date:       2003-07-30 8:19:43
[Download RAW message or body]

Wesley Reiley <WReiley@quickarrow.com> writes:

>Initially I am simply looking to use the Turbine 2.3 Intake with Turbine
>2.2, which is going really well. I am writing unit tests in the Turbine 2.3
>tree for intake to give my team confidence that it does everything we need
>correctly.

>Features I'd like, and will most likely look at adding if they are not
>already planned by a Turbine team member:

>1. Attaching some kind of javascript validation to the xml field
>definitions. Essentially I'm looking for Jakarta Commons Validation like
>functionality.

That would be great. While I'm not happy with the structure of the
commons-validation package, using it would vastly expand the abilities
of Intake.

>2. Be able to specify which class is used for each field type. Essentially I
>want to be able to pass a String like "1,000.00" into the BigDecimalField
>and have it strip out the commas (or periods in other locales); this seems
>like something that belongs in a custom class and not the core
>BigDecimalField class.

Sounds like attaching an input filter to a field before passing its result
to the validator.

>3. Have Locale specific validators, specifically the DateStringValidator.
>Instead of specifying different formats one could specify the locale. This
>can be implemented without effecting the Turbine source.

+1

>4. The ability to specify the "default" validator for a type. This is free
>if #2 is implemented.
>5. Although minor, the ability to associate short names with class names. I
>believe this is supported as long as all the validators are in the same
>package, and that package is the one specified at the top of the intake.xml
>file. Essentially I'm thinking some kind of mapping at the top of the
>intake.xml file so that the fields themselves don't have to have fully
>qualified names.

That sounds good. However, in the long run, I consider that a major
rewrite of Intake would be better than trying to add "yet another
feature" to the Intake validators. Some of the concepts (like the
dreaded intake tool) are IMHO not really well thought out.

>I've seen discussions in the archive referring to having Intake use the
>Commons Validators engine for the validation. I think this would be a
>worthwhile effort but don't believe I would have time to look at such an
>effort so I have kind of discounted this solution.

>I'm not trying to push these feature per se, they are just things my team
>desires and Colin Chalmers asked what things I felt were missing. 

Cool. If you have any code, I'm happy to put it into the proposals section.

	Regards
		Henning



>Thanks,
> - Wes Reiley

>-----Original Message-----
>From: Colin Chalmers [mailto:colin.chalmers@xs4all.nl]
>Sent: Sunday, July 20, 2003 6:26 AM
>To: Turbine Developers List
>Subject: Re: Intake


>> I am looking at using Intake, however the Turbine 2.2 release is missing
>> some features I need. I have looked at both the Turbine 2.3 and the
>Fulcrum
>> source trees, and both have most of the features (and bug fixes) I need.
>> Which of these is the current tree? It appears from cvs that the Turbine
>> tree contains more recent modifications, however the mailing list
>indicates
>> that Turbine 2.3 and Fulcrum 1.0 will be released at the same time, so I
>am
>> at a lost as to which tree to use and/or enhance. I'd like to use the
>active
>> tree so that I can keep my tree up-to-date and/or submit my enhancements
>for
>> inclusion into cvs.
>>
>> Thanks,
>>  - Wes

>Hi Wesley,

>You mention that the IntakeService in 2.3 contains "most of the features"
>you need. What are you missing?

>Colin

>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>>
>>


>---------------------------------------------------------------------
>To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

>---------------------------------------------------------------------
>To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen          INTERMETA GmbH
hps@intermeta.de        +49 9131 50 654 0   http://www.intermeta.de/

Java, perl, Solaris, Linux, xSP Consulting, Web Services 
freelance consultant -- Jakarta Turbine Development  -- hero for hire

"You are being far too rational for this discussion."  
       --- Scott Robert Ladd in <3F1874B0.6030507@coyotegulch.com>

---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]