Re: turbine 2.2 in CVS

[Jake Fear]

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:[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]>