I just added my patches into Scarab. TTWS28 & TTWS29 > -----Original Message----- > From: Jake Fear [mailto:[EMAIL PROTECTED]] > Sent: Monday, December 23, 2002 11:50 AM > To: Turbine Users List > Subject: Re: turbine 2.2 in CVS > > > Understood, thanks for clearing that up. Will this functionality be > rolled into the 2.2.1 or 2.3 releases when they are finalized? Also, > one last thing while we are on the topic and I will cease to > pester you > about this. In looking at the DateStringValidator I think I > discovered > a problem. In the 'public Date parse(String) throws ParseException' > method I believe there is a bug in the 2_2 branch, and perhaps it has > been resolved. If you have specified a list (1 or more) formats all > exceptions are ignored during the parse, which makes sense. > However, if > you have specified formats then the default df variable will will be > null, and the final attempt to format with that instance > variable will > not be executed. Thus, the local date variable is null and > is returned > as such. It seems that instead it should throw and > exception. I have > patched it as such on my machine, and it seems to give the expected > behavior. I have pasted the method below. I posted this > before, but I > got now response on it. If I am off base, could you tell me > how? The > code I added is at the bottom, right before the return statement. > > public Date parse(String s) > throws ParseException > { > Date date = null; > > if (s == null) > { > throw new ParseException("Input string was null", -1); > } > > for (int i = 0; i < dateFormats.size(); i++) > { > sdf.applyPattern((String)dateFormats.get(i)); > > try > { > date = sdf.parse(s); > } > catch (ParseException e) > { > // ignore > e.printStackTrace(); > } > > if (date != null) > { > break; > } > } > > if ((date == null) && (df != null)) > { > date = df.parse(s); > } > > if (date == null) > { > throw new ParseException("Could not match to any > format", -1); > } > > return date; > } > > > Quinton McCombs wrote: > > >The only way that you will get that functionality right now is to > >switch to the fulcrum version. Within the next few days, it will > >should be available in T 2.2 HEAD. I have completed my work on the > >service. I am just waiting for scarab to become available so that I > >can post the patches. > > > >If you can wait, the new version will have updated docs > (including an > >updated and commented DTD). Exception handling and > reporting has also > >been improved. A few bug fixes have also been implemented. If you > >look through the messages on the list over the past 2 - 3 days, you > >will find a more complete list of the changes being made. > > > > > > > >>-----Original Message----- > >>From: Jake Fear [mailto:[EMAIL PROTECTED]] > >>Sent: Monday, December 23, 2002 11:33 AM > >>To: Turbine Users List > >>Subject: Re: turbine 2.2 in CVS > >> > >> > >>I am not seeing this behavior in my own application. I > >>checked out from > >>the branch names TURBINE_2_2_BRANCH and the DateStringField > does not > >>override the toString() method in that code line. Perhaps I > >>am "barking > >>up the wrong branch." ;-) Thinking this might be the case I also > >>grabbed the HEAD tag to see if it lived there. No such luck. > >> Can you > >>please tell me where I can grab this functionality. It does > >>sound like > >>I would be reinventing the wheel for the most part. > >> > >>Cheers, > >>Jake > >> > >>Quinton McCombs wrote: > >> > >> > >> > >>>There is something close to this for the DateString field. The > >>>toString() method will use the first format rule for the field to > >>>format the date. This is actually in the Fulcrum version > >>> > >>> > >>which I have > >> > >> > >>>just completed back porting to T2.2. > >>> > >>>What would be ideal is one definition (formatter/mask) that > >>> > >>> > >>is used for > >> > >> > >>>both validation and display. This is what I really like > >>> > >>> > >>about the way > >> > >> > >>>that the DatString field is implemented. It used the first > >>> > >>> > >>format mask > >> > >> > >>>for display. You can still have other masks that will allow other > >>>formats for the input. > >>> > >>> > >>> > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: Jake Fear [mailto:[EMAIL PROTECTED]] > >>>>Sent: Monday, December 23, 2002 2:09 AM > >>>>To: Turbine Users List > >>>>Subject: Re: turbine 2.2 in CVS > >>>> > >>>> > >>>>I'm considering adding the capability to specify a > formatter for a > >>>>field. I don't want to dupliate any effort. Can you tell me if > >>>>anyone else is working on such a feature already? It does not > >>>> > >>>> > >>appear like it > >> > >> > >>>>would be difficult, provided a few assumptions. > >>>>1.) There is no need to have several formatters for a field, > >>>>one should > >>>>always suffice. > >>>>2.) Specifying a formatter is optional. > >>>>3.) If a formatter is specified, it will be used in the > >>>>toString() call > >>>>of the Field class. If not formatter is specified, the > >>>>current behavior > >>>>will be used. > >>>> > >>>>I think this is a good way to remain backward compatible and have > >>>>minimum impact on the API, while at the same time allow those > >>>>who want > >>>>to leverage the solution to do so with little or now code > >>>>change (they > >>>>may need to rip out any existing solutions to use this one). The > >>>>implementation would be similar to that for rules, only > >>>> > >>>> > >>significantly > >> > >> > >>>>simpler. I think this really completes the "Field" > >>>> > >>>> > >>abstraction, and > >> > >> > >>>>simplifies the writing of templates that must deal with dates, > >>>>currencies and the like. > >>>> > >>>>Cheers, > >>>>Jake > >>>> > >>>>Quinton McCombs wrote: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>The DTD is out of date. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>-----Original Message----- > >>>>>>From: Jake Fear [mailto:[EMAIL PROTECTED]] > >>>>>>Sent: Monday, December 23, 2002 1:55 AM > >>>>>>To: Turbine Users List > >>>>>>Subject: turbine 2.2 in CVS > >>>>>> > >>>>>> > >>>>>>I am building from the 2.2 branch in CVS. Can anyone tell > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>me why the > >>>> > >>>> > >>>> > >>>> > >>>>>>displayName attribute of an intake group does not appear in the > >>>>>>intake.dtd? I actually rely on this attribute, and I am > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>concerned it > >>>> > >>>> > >>>> > >>>> > >>>>>>may be removed from future versions of the product. Perhaps > >>>>>>it is very > >>>>>>new and only appears in the code. In any instance, I have > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>added it > >>>> > >>>> > >>>> > >>>> > >>>>>>myself, and the implementing code seems to work fine. > >>>>>> > >>>>>>Jake > >>>>>> > >>>>>> > >>>>>>-- > >>>>>>To unsubscribe, e-mail: > >>>>>><mailto:turbine-user-> [EMAIL PROTECTED]> > >>>>>>For > >>>>>>additional commands, > >>>>>>e-mail: <mailto:[EMAIL PROTECTED]> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>-- > >>>>>To unsubscribe, e-mail: > >>>>> > >>>>> > >>>>> > >>>>> > >>>><mailto:turbine-user-> [EMAIL PROTECTED]> > >>>> > >>>> > >>>> > >>>> > >>>>>For > >>>>> > >>>>> > >>>>> > >>>>> > >>>>additional commands, > >>>>e-mail: > >>>> > >>>> > >>>> > >>>> > >>>>><mailto:[EMAIL PROTECTED]> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>-- > >>>>To unsubscribe, e-mail: > >>>><mailto:turbine-user-> [EMAIL PROTECTED]> > >>>>For > >>>>additional commands, > >>>>e-mail: <mailto:[EMAIL PROTECTED]> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>-- > >>>To unsubscribe, e-mail: > >>> > >>> > >><mailto:turbine-user-> [EMAIL PROTECTED]> > >> > >> > >>>For > >>> > >>> > >>additional commands, > >>e-mail: > >> > >> > >>><mailto:[EMAIL PROTECTED]> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >> > >>-- > >>To unsubscribe, e-mail: > >><mailto:turbine-user-> [EMAIL PROTECTED]> > >>For > >>additional commands, > >>e-mail: <mailto:[EMAIL PROTECTED]> > >> > >> > >> > >> > > > > > >-- > >To unsubscribe, e-mail: > <mailto:turbine-user-> [EMAIL PROTECTED]> > >For > additional commands, > e-mail: <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > > > -- > To unsubscribe, e-mail: > <mailto:turbine-user-> [EMAIL PROTECTED]> > For > additional commands, > e-mail: <mailto:[EMAIL PROTECTED]> > >
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
