Develop freemarker templates for implented tags

[GoogleCodeExporter]

Tag rendering is currently only implemented with javatemplates plugin.
Skeleton for freemarker implementation exists, but freemarker templates
need to be implemented for all tags:
- head
- anchor
- div
- submit
- tabbedPane & tab

Original issue reported on code.google.com by obinna@gmail.com on 24 Feb 2009 at 2:03

[GoogleCodeExporter]

Original comment by obinna@gmail.com on 24 Feb 2009 at 2:09

• Changed title: Develop freemarker templates for implented tags

[GoogleCodeExporter]

Hey dude, hows it going? I sent u an email weeks ago, Im interested in joining 
the
project. Ive already did an read only checkout and started working in the 
datepicker
and the grid tag (im using jqGrid plugin, but im hoping that ui 1.8 comes with 
the
oficial Grid, then I'll update the freemarker templates).

Original comment by daniel.r...@gmail.com on 3 Jun 2009 at 9:09

[GoogleCodeExporter]

Hi Daniel,
Thanks for the help.  As you'll see with a recent you check-out, I finally got 
around
to doing the freemarker templates for all the tags, so now they're all 
implemented in
both freemarker and java-templates.
I was going to integrate a datepicker, but I've been trying to wrap my head 
around
providing a date-picker with multicalendar support (different calendar systems) 
which
is a requirement I've come across a few times. I don't think there's much 
existing
out there client-side for this and it's a pretty big task.
The stuff is pretty well tested now (I've been using on a project for a while 
now) so
I'm going to get back in touch with the guys and try to submit this as proper 
plugin
or even get into the struts sandbox.
I need to start closing some these issues. 
The biggest things at the moment are the documentation and maybe some kind of 
test app.

Original comment by obinna@gmail.com on 3 Jun 2009 at 9:39

• Changed state: Done

[GoogleCodeExporter]

Hi! Thanks for the response.
Im really looking forward to help you with all those things. Im a java 
architect with
long experience, so if you're interested add me as a project member and I'll be 
glad
to help you out.

Original comment by daniel.r...@gmail.com on 4 Jun 2009 at 5:08

[GoogleCodeExporter]

BTW, for the multicalendar support, you should checkout the Filament Group 
solution:
http://www.filamentgroup.com/lab/date_range_picker_using_jquery_ui_16_and_jquery
_ui_css_framework/

Those guys are supporting jQueryUI, they have developed the ThemeRoller concept 
and
application.
I really think that your plugin should support other components, such as: grid, 
tree,
slider, etc. While we dont have some of these components in the oficial UI 
library
yet, we are able to use some stable jQuery plugin (such as the great jqGrid:
http://www.trirand.com/jqgrid35/jqgrid.html) and when they release the oficial
version of the UI with that component we refactor the plugin to support the 
oficial
component.

I really think we are able to provide a great plugin and it can easily enter the
struts sandbox and be one of the main Struts2 plugin!

Original comment by daniel.r...@gmail.com on 4 Jun 2009 at 11:43

[GoogleCodeExporter]

By multi-calendar support, I meant actually supporting multiple calendar systems
(like Gregorian, Julian, Coptic, Japanese etc.). Some of these have odd things, 
like
13 months in a year and some months with 5 days only etc.

In geneal though, I have opted for a simple/lean approach which doesn't include 
too
many widgets initially. There are so many out there, I don't to make the 
framework
too heavy and users can integrate their on if absolutely necessary. It made 
sense to
me that a good way to limit the scope is to only implement widgets that are 
already
part of the jQuery-UI release.

Having said that, there are some released UI widgets which I haven't yet 
integrated.
Most noteably: progressbar, slider and datepicker (b/c of multi-calendar).

I know it's tempting to want to add all the bells and whistles but I'd rather 
take a
more cautious approach which will also minimize the maintenance tasks which 
could be
significant for some of these components if they aren't final releases yet. I 
think
the best thing would be to integrate these properly first before thinking of
un-released plugins...

IMO, Doing too much - getting to heavy and not being able to maintain the 
framework -
was what largely sunk the dojo plugin in the first place

Original comment by obinna@gmail.com on 4 Jun 2009 at 3:00