On 12/11/06, Claude Brisson <[EMAIL PROTECTED]> wrote:
Le lundi 11 décembre 2006 à 09:45 -0800, Nathan Bubna a écrit :
> On 12/9/06, Claude Brisson <[EMAIL PROTECTED]> wrote:
> > Looks very cool. That's a lot of work!
> >
> > Some remarks:
> >
> >  - Alternator: we'd like the hand-made examples to return several
> > values... not that important.
>
> not sure i understand...

Just that when I give the alternator ['blue','red'], I'd like to see
"blue, red, blue" rather than just "blue" (that is, it should be
evaluated several times). Really not that important.

nah.  i'd like to keep the function demos realistic.  things like that
can go in a "full demo" at the bottom, such as the ones that
IteratorTool or SearchTool have.  i've actually been adding a few more
of these and will check them in shortly.

> >  - Date
> >         $date.getDay("[   ]")
> >         $date.getMont("[   ]")
> >         $date.getYear("[   ]")
> >
> > those three methods take a Date argument, so the text field doesn't help
> > much... in fact we should also have string versions for those three
> > methods (that rely on toDate()).
>
> actually, those three methods take an Object argument which is
> automatically fed through toCalendar(Object) which eventually
> delegates to toDate(Object) whose last resort is parsing the String
> value of the Object.  So, they can be used as is.  However, i agree
> that they're not especially useful like this.  i'll drop the quotes
> around the DateTool function examples.

Ok, I browsed the sources too fast. But I did so after having tried 3 or
4 different syntaxes in the field getDay("[    ]"), which every newcomer
will do as well... This time I tracked the trail to its very end and saw
that the default behaviour is to fetch a date time medium format, which
means the only string that works is "Dec 11, 2006 9:07:05 PM", wich is
ok as a default formatting string but not so smart when it comes to
parsing... We should include some guessing algorithm, and I'm sure we
can easily find a pretty one around there in the apache codebase just
waiting for us.

that would be cool.  the string -> date parsing of
DateTool.toDate(Object) is simplistic at best by default.  if you use
the same format for output and input, then you can configure DateTool
to use that as the default.  otherwise, you should use
DateTool.toDate(String format, Object date) or one of the other
toDate() methods.

so basically, there's plenty of capability in DateTool, but only
limited "magic".  improvements are welcome!

> >  - Cookie
> >
> > $cookie.all should be displayed with a #foreach, so that we actually see
> > the cookies. Minor.
>
> can do.
>
> >
> > The CSS layout rocks! Maybe we can use it by default.
>
> i guess we could.  hadn't really thought about it.
>
> > Last but not least, this webapp could serve as a basis for testcases.
> > Talking about this, I built a testcase for Velosurf (both whitebox and
> > blackbox using Jetty), so maybe I can work on this for the Tools.
>
> interesting idea.  would this be automated or automate-able?

Could not be more automated. Downloads needed jars, starts Jetty,
submits forms, compares results, stops Jetty. And what is cool is that
you can manually launch the ant target "start-jetty" and point your
browser to -let's say, localhost:8081, when you need to debug the
testcases themselves.

It uses HttpUnit to do so. The HttpUnit licence is not an ASF one, but
is clearly compatible (never seen a shorter licence:
http://httpunit.sourceforge.net/doc/license.html ) and already used by
several apache projects.

sounds awesome!  i'd definitely be interested in exploring such things.

  Claude

> >
> >   Claude
> >
> > Le vendredi 08 décembre 2006 à 12:02 -0800, Nathan Bubna a écrit :
> > > hey folks,
> > >
> > > you probably noticed that i just checked in a new example app for
> > > VelocityTools to replace the "layout" example.  this is something i've
> > > been thinking of doing for years, and finally got around to doing.
> > >
> > > basically, it provides demonstrations (most of which are interactive)
> > > of all the Generic and VelocityView tools we have.  there is certainly
> > > plenty of room for improvement in the usefulness of the examples, but
> > > i figured it was time to get it out and see what ya'll think.
> > >
> > > if some of you were willing to check it out and give it a test run,
> > > i'd love to get some feedback.
> > >
> > > It's easy:
> > > - check out the latest revision of VelocityTools from svn
> > > - run 'ant showcase'
> > > - follow the instructions printed out at the end
> > >
> > > thanks!
> > >
> > > p.s. VelocityView and the Generic Tools are largely ready for a 1.3
> > > release.  if anyone wants to help me get 1.3 out the door, i'd love
> > > some help updating the VelocityStruts dependencies and making sure
> > > VelocityStruts is fully compatible with the Struts 1.3.x series.
> > > (Marino?)  Please note that with Tiles going independent as a TLP and
> > > Struts 2.x soon on the way, the future of VelocityStruts beyond
> > > VelocityTools 1.3 is very much in question.
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to