freemarker-devel Mailing List for FreeMarker template engine (Page 474)
Generates text that depends on changing data (like dynamic HTML).
Brought to you by:
revusky
This list is closed, nobody may subscribe to it.
2000 |
Jan
(4) |
Feb
|
Mar
|
Apr
(4) |
May
(2) |
Jun
(47) |
Jul
(7) |
Aug
(15) |
Sep
|
Oct
(5) |
Nov
(9) |
Dec
(9) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(39) |
Feb
(27) |
Mar
(18) |
Apr
(25) |
May
(44) |
Jun
(35) |
Jul
(12) |
Aug
(66) |
Sep
(44) |
Oct
(36) |
Nov
(31) |
Dec
(2) |
2002 |
Jan
(11) |
Feb
(16) |
Mar
(342) |
Apr
(158) |
May
(387) |
Jun
(288) |
Jul
(185) |
Aug
(225) |
Sep
(400) |
Oct
(518) |
Nov
(238) |
Dec
(453) |
2003 |
Jan
(627) |
Feb
(425) |
Mar
(350) |
Apr
(250) |
May
(348) |
Jun
(473) |
Jul
(442) |
Aug
(335) |
Sep
(146) |
Oct
(82) |
Nov
(141) |
Dec
(56) |
2004 |
Jan
(125) |
Feb
(127) |
Mar
(144) |
Apr
(16) |
May
(42) |
Jun
(30) |
Jul
(27) |
Aug
(51) |
Sep
(64) |
Oct
(50) |
Nov
(39) |
Dec
(27) |
2005 |
Jan
(76) |
Feb
(13) |
Mar
(33) |
Apr
(63) |
May
(57) |
Jun
(399) |
Jul
(95) |
Aug
(64) |
Sep
(44) |
Oct
(112) |
Nov
(76) |
Dec
(39) |
2006 |
Jan
|
Feb
(60) |
Mar
(139) |
Apr
(103) |
May
(124) |
Jun
(59) |
Jul
(49) |
Aug
(24) |
Sep
(26) |
Oct
(3) |
Nov
(20) |
Dec
(17) |
2007 |
Jan
(13) |
Feb
(7) |
Mar
(23) |
Apr
(37) |
May
(45) |
Jun
(47) |
Jul
(60) |
Aug
(84) |
Sep
(32) |
Oct
(24) |
Nov
(43) |
Dec
(32) |
2008 |
Jan
(27) |
Feb
(35) |
Mar
(80) |
Apr
(124) |
May
(22) |
Jun
(9) |
Jul
(54) |
Aug
(55) |
Sep
(21) |
Oct
(26) |
Nov
(39) |
Dec
(21) |
2009 |
Jan
(20) |
Feb
(42) |
Mar
(53) |
Apr
(8) |
May
|
Jun
(17) |
Jul
(11) |
Aug
(4) |
Sep
(61) |
Oct
(14) |
Nov
(13) |
Dec
(16) |
2010 |
Jan
(29) |
Feb
(56) |
Mar
(67) |
Apr
(3) |
May
(58) |
Jun
(63) |
Jul
(117) |
Aug
(35) |
Sep
(15) |
Oct
(2) |
Nov
(3) |
Dec
(4) |
2011 |
Jan
(5) |
Feb
|
Mar
|
Apr
|
May
(32) |
Jun
(47) |
Jul
(1) |
Aug
|
Sep
(5) |
Oct
(7) |
Nov
|
Dec
(3) |
2012 |
Jan
|
Feb
(9) |
Mar
(11) |
Apr
(9) |
May
|
Jun
(4) |
Jul
(1) |
Aug
(14) |
Sep
(7) |
Oct
(6) |
Nov
|
Dec
(3) |
2013 |
Jan
(8) |
Feb
(3) |
Mar
(8) |
Apr
(4) |
May
(5) |
Jun
(36) |
Jul
(52) |
Aug
(8) |
Sep
(1) |
Oct
(9) |
Nov
(17) |
Dec
(7) |
2014 |
Jan
(3) |
Feb
(4) |
Mar
(2) |
Apr
(2) |
May
(7) |
Jun
(7) |
Jul
(28) |
Aug
(16) |
Sep
(6) |
Oct
(3) |
Nov
(1) |
Dec
|
2015 |
Jan
(8) |
Feb
(3) |
Mar
(2) |
Apr
(4) |
May
(13) |
Jun
(48) |
Jul
(9) |
Aug
(9) |
Sep
(22) |
Oct
(3) |
Nov
(1) |
Dec
(1) |
2016 |
Jan
(8) |
Feb
(2) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
(3) |
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(3) |
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
From: <ar...@hs...> - 2001-02-15 17:47:37
|
Hi, i justed checked the CVS Tree and noticed some changes, mostly by Travis. Please, if you change something, send me a note o.k.? And if you add code, please tell me! I summarized the changes at the end of this mail. Secondly, i applied some of the open patches from the patch manager at sourceforge. Nicholas Cull has send in 8 patches, i assigned two of them to Travis, since they are for the guestbook example and Travis changed the guestbook example to reflect the new features of TemplateListModel. Travis, could you please check the patches and change the example accordingly? t.i.a. There are three HUGE patches left, which change the JavaDoc. Since my bin/p= atch chokes even on the smallest patches (don=B4t now why?!), i can=B4t apply th= em. Nicholas, could you please check out the current CVS version, apply the patches and send me back the changes files? t.i.a. After that, i would be very please if some people could check out the current CVS version, test it and report bugs to this list/the sourceforge bug tracking.=20 I posted the taglib and some people d/l=B4ed it, but there was no response on that. I=B4ll just leave the archive at the current location and WAIT FOR FEEDBACK! Please, could SOME people take a look at that code and post comments?=20 Cheers Holger --=20 Holger Arendt ar...@hs... | D=FCsseldorfer Linux User Gr= oup | http://www.dlug.de Java auf den Punkt gebracht: | --------------------------- http://www.classpath.de | PGP public key available |
From: <nj...@so...> - 2001-02-14 22:53:42
|
From my understanding of the 1.5.3 release, the listSize() method is not used at all at the moment. There's currently a patch in the FreeMarker patch manager to allow templates to access it, but for the moment the meaning of listSize() appears to be undefined. Nicholas. Szegedi Attila writes: > Hi all, > > I need to make some decisions regarding updating Expose to work with > Freemarker 1.5.3, and I'd like to discuss them first. > TemplateListModel got methods listSize() and get(int) for random access in > 1.5.3. > Expose right now wraps java.util.Iterator and java.util.Enumeration > instances into TemplateListModel; implementing get(int) for these is > relatively easy, but implementing listSize() is not trivial at all since an > iterator does not know its size. > > I have several ideas: > - always return Integer.MAX_VALUE for size and hope calling code relies on > hasNext() rather than on listSize(). > - return iteratedSoFar + hasNext() ? 1 : 0, where iteratedSoFar is the > number of times next() was called successfully this far. This would make > constructs like "for(int i = 0; i < list.listSize(); ++i) ..." work. > However, it would defeat optimizations like "int l = listSize(); for(int i = > 0; i < l; ++i) ..." that rely on listSize() having constant value. > - for ListIterators, call next() repeatedly to calculate list size, then > move back to current location with previous() calls. For some iterators this > could be a performance killer. > - return -1 to indicate unknown size. However, in this case Freemarker API > specification should explicitly document -1 as a legal return value meaning > "unknown size". > - simply throw UnsupportedOperationException() to flag this part of the > interface is not supported. However, I really hate this approach for > philosophical reasons (if I implement an interface, then I shouldn't choose > not to support a part of it). > > Comments anyone? > Attila. |
From: <nj...@so...> - 2001-02-14 22:50:27
|
Yes, I noticed that, too. Trying to be a good open source citizen, I added a bunch of patches to the FreeMarker patch manager which brings the documentation up-to-date against the 1.5.3 release. I hope they will make it into the devel tree at some stage. Nicholas. Szegedi Attila writes: > After downloading 1.5.3 I have noticed that the README.html and the API Docs > seem to be pre-1.5.3. > > Attila. > |
From: Szegedi A. <sze...@fr...> - 2001-02-13 21:52:22
|
After downloading 1.5.3 I have noticed that the README.html and the API Docs seem to be pre-1.5.3. Attila. |
From: Szegedi A. <sze...@fr...> - 2001-02-13 21:50:00
|
Hi all, I need to make some decisions regarding updating Expose to work with Freemarker 1.5.3, and I'd like to discuss them first. TemplateListModel got methods listSize() and get(int) for random access in 1.5.3. Expose right now wraps java.util.Iterator and java.util.Enumeration instances into TemplateListModel; implementing get(int) for these is relatively easy, but implementing listSize() is not trivial at all since an iterator does not know its size. I have several ideas: - always return Integer.MAX_VALUE for size and hope calling code relies on hasNext() rather than on listSize(). - return iteratedSoFar + hasNext() ? 1 : 0, where iteratedSoFar is the number of times next() was called successfully this far. This would make constructs like "for(int i = 0; i < list.listSize(); ++i) ..." work. However, it would defeat optimizations like "int l = listSize(); for(int i = 0; i < l; ++i) ..." that rely on listSize() having constant value. - for ListIterators, call next() repeatedly to calculate list size, then move back to current location with previous() calls. For some iterators this could be a performance killer. - return -1 to indicate unknown size. However, in this case Freemarker API specification should explicitly document -1 as a legal return value meaning "unknown size". - simply throw UnsupportedOperationException() to flag this part of the interface is not supported. However, I really hate this approach for philosophical reasons (if I implement an interface, then I shouldn't choose not to support a part of it). Comments anyone? Attila. |
From: Lucas G. <lu...@wo...> - 2001-02-08 16:41:07
|
Actually, XPath matching is much needed to do this. Otherwise you end up rewriting it, only not nearly as well. - Lucas _________ Information wants to be $6.95 > -----Original Message----- > From: fre...@li... > [mailto:fre...@li...]On Behalf Of Holger > Arendt > Sent: Thursday, February 08, 2001 11:20 AM > To: fre...@li... > Subject: Re: [Freemarker-devel] Recursive HTML Generation > > > Hi Andreas, > > Andreas Mueller writes: > > > > What is the best way to handle this recursive data with free marker? I > > read about the TemplateMethodModel. Is that is the way to do it? > > If your code is well formed enough to be XML ;-), you could use > something like JDom to access the files within some new classes > (e.g. a BlockListModel and a BlockHashModel class), > where BlockListModel |>--- BlockHashModel. > > So, TemplateListModel and TemplateHashModel are your friends :-) > > If your "blocks" look like > > <block> > <block> > </block> > <block> > </block> > </block> > > The BlockListModel would allow you to do > > (add "new BlockListModel("/path/to/some/block/file")" as "blocks" > to the TemplateRootModel) > > <foreach block in blocks> > ${block.type} contains ${block.htmlContent} > with ${block.countInnerBlocks()} nested Blocks: > > <foreach innerBlock in block> > .... > </foreach> > </foreach> > > ( "block" is now a BlockHashModel, ) > > > Cast your vote for SwiftMQ as Best Java Messaging & Middleware Tool: > Nice product, btw. :-) > > HTH > > Cheers > Holger > > -- > Holger Arendt ar...@hs... | Düsseldorfer Linux User Group > | http://www.dlug.de > Java auf den Punkt gebracht: | --------------------------- > http://www.classpath.de | PGP public key available > > _______________________________________________ > Freemarker-devel mailing list > Fre...@li... > http://lists.sourceforge.net/lists/listinfo/freemarker-devel > |
From: Andreas M. <am...@ii...> - 2001-02-08 16:33:34
|
> > What is the best way to handle this recursive data with free marker? > I > > read about the TemplateMethodModel. Is that is the way to do it? > > If your code is well formed enough to be XML ;-), you could use > something like JDom to access the files within some new classes > (e.g. a BlockListModel and a BlockHashModel class), > where BlockListModel |>--- BlockHashModel. > > So, TemplateListModel and TemplateHashModel are your friends :-) Thanks, Holger! I will try to learn what you mean... ;-) > > Cast your vote for SwiftMQ as Best Java Messaging & Middleware Tool: > Nice product, btw. :-) Yeah! I know! Vote! Cheers, Andreas |
From: <ar...@hs...> - 2001-02-08 16:24:24
|
Hi Andreas, Andreas Mueller writes: =20 > What is the best way to handle this recursive data with free marker? I=20 > read about the TemplateMethodModel. Is that is the way to do it? If your code is well formed enough to be XML ;-), you could use something like JDom to access the files within some new classes (e.g. a BlockListModel and a BlockHashModel class), where BlockListModel |>--- BlockHashModel.=20 So, TemplateListModel and TemplateHashModel are your friends :-) If your "blocks" look like <block> <block> </block> <block> </block> </block> The BlockListModel would allow you to do (add "new BlockListModel("/path/to/some/block/file")" as "blocks" to the TemplateRootModel) <foreach block in blocks> ${block.type} contains ${block.htmlContent} with ${block.countInnerBlocks()} nested Blocks: <foreach innerBlock in block> .... </foreach> </foreach> ( "block" is now a BlockHashModel, ) > Cast your vote for SwiftMQ as Best Java Messaging & Middleware Tool: Nice product, btw. :-)=20 HTH Cheers Holger --=20 Holger Arendt ar...@hs... | D=FCsseldorfer Linux User Gr= oup | http://www.dlug.de Java auf den Punkt gebracht: | --------------------------- http://www.classpath.de | PGP public key available |
From: Andreas M. <am...@ii...> - 2001-02-08 10:28:34
|
Hi there, I was looking for a template engine and came along free marker which seems very easy and impressive. But - as usual - I'm in the situation that I have to convert existing stuff to use with free marker. Our current system is a self created template engine but reach now its limits. Base of all our HTML are XML like textfiles which contains text blocks and wíthin this text block there might be other blocks, marked as tables or code elements. You can see the results in the various pages on http://www.swiftmq.com. This for the intro, now my question: What is the best way to handle this recursive data with free marker? I read about the TemplateMethodModel. Is that is the way to do it? Thanks in advance! -- Andreas Mueller, am...@ii..., IIT GmbH, Bremen/Germany, http://www.iit.de SwiftMQ - JMS Enterprise Messaging System, http://www.swiftmq.com ----------------------------------------------------------------------- Cast your vote for SwiftMQ as Best Java Messaging & Middleware Tool: QuickVote at: http://www.swiftmq.com/jdjvote.html ----------------------------------------------------------------------- |
From: <ar...@hs...> - 2001-02-07 17:00:31
|
Hi Alex, Alexander Petrushko writes: >=20 > In light of Freemarker being a bit behind the curve as far as new > features and development is concerned, I no longer feel qualified > to object. Sorry for that ...=20 --=20 Holger Arendt ar...@hs... | D=FCsseldorfer Linux User Gr= oup | http://www.dlug.de Java auf den Punkt gebracht: | --------------------------- http://www.classpath.de | PGP public key available |
From: <ar...@hs...> - 2001-02-07 17:00:30
|
Hi Attila, Szegedi, Attila writes: >=20 > It's basically OK for me. Do you want to change package names as well? I think Expose would be ideal for the fm taglib, so moving it into something like freemarker.reflection.* would be nice.=20 > What is the majority standpoint on this issue now? If the majority votes against a freemarker.reflection package, we should also move the taglib outside the freemarker.* package structure.=20 =20 > Also, what should be changed to ensure 1.5.3 compatibility? I think the get() and listSize() methods from TemplateListModel are not=20 implemented. =20 > In fact, this feature already exists in Expose in a true Freemarker > spirit: > Again, this is easy to improve if people vote for it. +1 from me for this feature :-) Cheers Holger --=20 Holger Arendt ar...@hs... | D=FCsseldorfer Linux User Gr= oup | http://www.dlug.de Java auf den Punkt gebracht: | --------------------------- http://www.classpath.de | PGP public key available |
From: Alexander P. <alpet@OCF.Berkeley.EDU> - 2001-02-07 09:18:22
|
Hey guys, In light of Freemarker being a bit behind the curve as far as new features and development is concerned, I no longer feel qualified to object. Feel free to make this a freemarker.* package. Cheers, Alex From: "Szegedi, Attila" <sz...@sc...> Subject: RE: [Freemarker-devel] Re: jsp taglibs Date: Wed, 7 Feb 2001 10:02:07 +0100 > Before moving that to the freemarker. package structure (hope > that´s o.k. > for you, Attila?!), it should be compatible with version 1.5.3 of > Freemarker. Expose is really nifty, so using it instead of the adapter > classes from the taglib code would IMHO be much better. It's basically OK for me. Do you want to change package names as well? I have no objections on this either, I just remember the beginning of my work on Freemarker, when org.szegedi.expose was freemarker.reflection and Alex complained about feature bloat in freemarker core expressing his opinion that reflection support should be an optional package. What is the majority standpoint on this issue now? |
From: Szegedi, A. <sz...@sc...> - 2001-02-07 08:55:08
|
> -----Original Message----- > Behalf Of Holger Arendt > > > The expose version from the current release/cvs is not the > expose package. > A new and improved version can be found at .. (take a look at > http://freemarker.manilasites.com). Just to help out: http://lemma.scriptum.hu/people/szegedi/expose.zip and http://lemma.scriptum.hu/people/szegedi/expose-example.zip > > Before moving that to the freemarker. package structure (hope > that´s o.k. > for you, Attila?!), it should be compatible with version 1.5.3 of > Freemarker. Expose is really nifty, so using it instead of the adapter > classes from the taglib code would IMHO be much better. It's basically OK for me. Do you want to change package names as well? I have no objections on this either, I just remember the beginning of my work on Freemarker, when org.szegedi.expose was freemarker.reflection and Alex complained about feature bloat in freemarker core expressing his opinion that reflection support should be an optional package. What is the majority standpoint on this issue now? Also, what should be changed to ensure 1.5.3 compatibility? > > Yep, that´s what Expose does. Btw.: I would be really cool, if the > reflection code would first try getXX and than get("xx"). Perhaps > as an alternative option/flag. > In fact, this feature already exists in Expose in a true Freemarker spirit: if an object's class implements any TemplateModel, Expose will not wrap it into a reflection model (see ReflectionUtilities.wrap() method) but leave it unchanged. So Freemarker engine will call TemplateHashModel.get() on this object when evaluating the Dot operator. So the "alternative option/flag" is "implements TemplateHashModel" on the class. Of course, this behavior completely bypasses reflection for classes implementing any TemplateModel, so you cannot call getXx() on them... Again, this is easy to improve if people vote for it. Cheers, Attila. |
From: <ar...@hs...> - 2001-02-06 16:54:24
|
Hi Scott, Scott Hasse writes: > Holger, >=20 > I got your email to the list regarding the jsp taglib stuff, and was=20 > wondering what I can/should be working on. I moved and re-packaged your source a bit, added some legal notes (hopefully to all classes) to the sources (LGPL), so it conforms with the rest of the freemarker package, and changed the code a bit ( ModelProcessor, etc. ) Before adding it to the main cvs tree, I uploaded it to my server, so people can take a first look. If there is some major problem with the code, it=B4s IMHO easier to fix it outside CVS. I=B4ll add it to CVS after some feedback from the folks on this list, so everyone can hack on it :-) We=B4ll have to decide, what we want the taglib to do, so I think we will find something for you to=20 work on :-)) As an example, we need a way to call TemplateMethodModels and functions (but that=B4s another problem). > I have used cvs to checkout=20 > a version of Attila's reflection package you were talking about=20 > (is that the"expose" stuff?), but was wondering if you were going to=20 > move that into the main freemarker tree. The expose version from the current release/cvs is not the expose package. A new and improved version can be found at .. (take a look at http://freemarker.manilasites.com).=20 =20 Before moving that to the freemarker. package structure (hope that=B4s o.k. for you, Attila?!), it should be compatible with version 1.5.3 of Freemarker. Expose is really nifty, so using it instead of the adapter classes from the taglib code would IMHO be much better. > If so, I would prefer to hold off making any changes until that is set do= ne. Yes, that would be best.=20 > Also, I tried to get the code you modified at > http://www.classpath.de/fmtags.tgz > and wasn't able to access the server. =20 Huh? Scary idea :-) I saw some d/l in the access log, so please try again.= =20 If you encounter any problems, I=B4ll mail it to you or find another place for the package.=20 > I do think that some of the features=20 > I've implemented (such as testing for a getXxx method given an xxx key,= =20 > and testing for a get("xxx") method reflectively) would be useful as=20 > additions to the existing reflection model. Yep, that=B4s what Expose does. Btw.: I would be really cool, if the reflection code would first try getXX and than get("xx"). Perhaps as an alternative option/flag. =20 > I have a cvs server that I could temporarily put the code on until we=20 > get it into a state that we feel comfortable adding it to the main=20 > freemarker tree. If you think that might be a good idea, let me know. Hm.. let=B4s wait until Friday. If nobody sends any mail regarding the current state of the taglib code, I=B4ll add it to the Freemarker CVS on sourceforge.net =20 > Would you prefer I post them to the main list for discussion, or=20 > implement them on the code base as it sits? We should discuss new ideas on the list first. So everybody can contribute their ideas. But having some code at hand doesn=B4t hurt, either :-) =20 > Finally, I was wondering about your thoughts concerning tag naming. =20 > In an earlier posting, I suggested possibly adopting XSL style tags,=20 > with the advantage of being able to use existing XSL documentation. Hm.. for those users moving existing code to the taglib solution, using the freemarker naming is IMHO easier. Of course, we can=B4t use those naming style for everything (e.g. ${x} -> <fm:show name=3D"x"> ). Just post your ideas for this to the list, we=B4ll discuss it ... (and since everyone can change the .tld, we don=B4t have any real problems ... ) Cheers Holger --=20 Holger Arendt ar...@hs... | D=FCsseldorfer Linux User Gr= oup | http://www.dlug.de Java auf den Punkt gebracht: | --------------------------- http://www.classpath.de | PGP public key available |
From: <ar...@hs...> - 2001-02-03 12:20:16
|
Hi all, I moved all of Scott=B4s classes to freemarker.taglib, put everything under the LGPL and uploaded a first version to =20 http://www.classpath.de/fmtags.tgz=20 Please, check it out (example page, .tld and example web.xml included) and post feedback. Remember, this is a first version :-) We should improve the code and move everything into CVS afterwards. Mainly the ModelProcessor.java and the Adapter classes could be improved, but the test.jsp runs fine (and fast!). Havn=B4t tested a real world TemplateModel with the code, but it should work (hope so :-) I also think we should add the expose package into the "main" freemarker tree, so we can use them instead the classes from freemarker.taglib.adapter. Cheers Holger --=20 Holger Arendt ar...@hs... | D=FCsseldorfer Linux User Gr= oup | http://www.dlug.de Java auf den Punkt gebracht: | --------------------------- http://www.classpath.de | PGP public key available |
From: <ar...@hs...> - 2001-02-03 09:42:59
|
Hi Scott, Scott Hasse writes: >=20 > Holger: If it makes sense to put this in the contrib area, feel free, or > perhaps we can > work to make it a bit more feature rich and test it a bit before doing so. > Let me know how you want to proceed. I=B4ll take a look and post my ideas to the list, before adding it to the cvs repository. We should also take a look at the reflection code and the expose package from Attila and see, if we can merge them. Cheers Holger --=20 Holger Arendt ar...@hs... | D=FCsseldorfer Linux User Gr= oup | http://www.dlug.de Java auf den Punkt gebracht: | --------------------------- http://www.classpath.de | PGP public key available |
From: Scott H. <sco...@is...> - 2001-02-02 20:25:58
|
All, I have posted my project so that you can download it and try it. The entire project is available at: http://www.bikeaid.org/images/taglib.jar If you save this file to disk and then extract it, you should have a directory structure created with the following: /src - the source code files. /dist - a war file with the tag libraries already built in. If you are running tomcat, you can just deploy this to see the tags in action. Or, check out: http://www.bikeaid.org/taglib/test.jsp /bin - the ant.bat that needs to be run to do additional builds /conf - the xml files for the sample web app and tag lib descriptor /html - the test jsp there are some other directories, but those are largely unnecessary. If we want to start really working on this project, we should probably get it into a cvs repository somewhere. If you want to make changes and re-build the project, you will have to set your PROJECT_HOME and JAVA_HOME variables. If you have any issues, I can walk you through stuff via email as well. Some comments on the existing state of things: the current <if> and <choose> tags only test for non-nullness. If we want to integrate this with the existing freemarker stuff, we can use the same evaluation code that is used for the <if> stuff. Also, I have currently copied the template model interfaces. This would also be merged if we decide it is worthwhile to integrate this with freemarker. Feel free to take this stuff and do whatever you want with it. I have used com.isthmusgroup (my company) as a package name, but feel free to change it to whatever makes sense. Holger: If it makes sense to put this in the contrib area, feel free, or perhaps we can work to make it a bit more feature rich and test it a bit before doing so. Let me know how you want to proceed. Sincerely, Scott |
From: Crane, D. <David.Crane@TMS.TM3.COM> - 2001-02-01 23:07:34
|
Scott, I'd appreciate a copy of your code, too. List iteration, scalars and conditionals are all that are definitely needed, at least for our purposes. If we do use freemarker beyond our prototype (and I'll certainly push for that), I'll send any code changes back to you, or to this list, whichever is more appropriate. Thanks, David Crane |
From: <ar...@hs...> - 2001-02-01 17:13:35
|
Scott Hasse writes: > All, >=20 > Regarding the freemarker-like jsp tag posting, I did implement a "first > swipe" of nearly all of the freemarker tags in jsp syntax.=20 > If anyone is interested in this, please send me an > email and I can send you the source. > Anyway, I would be more than willing to send this code to anyone that was > curious, and perhaps it is something we could put in the contrib area. Please send me the source.=20 Cheers Holger --=20 Holger Arendt ar...@hs... | D=FCsseldorfer Linux User Gr= oup | http://www.dlug.de Java auf den Punkt gebracht: | --------------------------- http://www.classpath.de | PGP public key available |
From: Scott H. <sco...@is...> - 2001-01-31 21:14:58
|
All, Regarding the freemarker-like jsp tag posting, I did implement a "first swipe" of nearly all of the freemarker tags in jsp syntax. I have found that implementing custom tags is very straightforward, and implementing all of the tags so far has been less than a days' worth of work (albeit, they are not extensively tested). I don't have support yet for Method Models, or the <function> tag, but list iteration, scalars, conditionals, etc. are implemented and working. If anyone is interested in this, please send me an email and I can send you the source. >One point I don=B4t get right now is:=20 >If we have a tag like ><fm:show name=3D"foo.bar.baeh"/> >where does the foo come from? > > a) We have an object foo in the pageContext (which is a TemplateModel) > b) We only use a TemplateModel (containing stuff from session, application > etc.) > c) something weird ;-) > >I would like b), since then we would have a "standard" way to access >objects: >app. =3D=3D the application scope >session. =3D=3D the session scope >req. =3D=3D ... >page. =3D=3D ... >foo =3D=3D some page/application specific, or tools., images. ... In the tags I implemented, I used the page, request, session and application scopes as the only data model, and use reflective adapters (similiar to the ones in the contrib area) to provide template model interfaces to basically any object that exists in those contexts. I realize that this reflective layer may introduce some performance issues, but for my purposes, the ability to do a good design without coding numerous object-specific adapters was more than worth it. I took advantage of the servlet 2.2 PageContext.findAttribute() mechanism to look up objects. This method searches through the four contexts in a preset (and, IMHO good) order. So, in a way, the four contexts all together make up the "data model". We could certainly make context-specific addressing available, too, by supporting syntax such as <fm:show name="application.foo.bar"/> or <fm:show name="session.customer.name"/>, and the <assign name="" value="" scope=""/> as well. Regarding tag naming, I think using the freemarker names would be fine. However, oe problem is that since the tags need to be valid xml, things like the freemarker <if><else></if> won't work. One place where all of this syntax has been worked out is in XSL. They have a simple <if> tage, and a <choose> tag for more complex requirements, as well as many other useful display-type tags, including potentially useful things like very flexible number formatting. It might be a big benefit to be able to use all of the XSL documentation that is already out there for tags like that. Also, then html developers are, in essence, learning XSL syntax, which may serve them better in the long run. In any case, it is pretty easy to change tag names using the xml jsp tag deployment file. Anyway, I would be more than willing to send this code to anyone that was curious, and perhaps it is something we could put in the contrib area. Scott |
From: <ar...@hs...> - 2001-01-31 18:59:41
|
Hi David, Crane, David writes: > I do think that J2EE is catching on -- certainly it is where I work. > EJBs seem to hold promise for writing distributed multi-tier systems. Yep. =20 > These custom tags would be fairly intuitive for web designers (and > eventually JSP development tools should also be trainable, too). > Because the TemplateModel is also intuitive, a Java developer working > on the backend should be able to document a model structure for use by > a web designer working on the frontend. No Java code should ever be > necessary in the JSP. One point I don=B4t get right now is:=20 If we have a tag like <fm:show name=3D"foo.bar.baeh"/> where does the foo come from? a) We have an object foo in the pageContext (which is a TemplateModel) b) We only use a TemplateModel (containing stuff from session, application etc.) c) something weird ;-) I would like b), since then we would have a "standard" way to access objects: app. =3D=3D the application scope session. =3D=3D the session scope req. =3D=3D ... page. =3D=3D ... foo. =3D=3D some page/application specific, or tools., images. ... > On Dec. 11, Scott Hasse (sco...@is...) wrote: > >=20 > > Some things I like about JSP vs. Freemarker: > >=20 > > * It is currently considered more "standard". I don't enjoy having to > > explain/sell what Freemarker is to customers that already have JSP > deployed. That=B4s one of the biggest problems with Freemarker (or, I guess, any other template language"): "is it a standard??" > > So, here are my initial thoughts: > >=20 > > * The "data model" paradigm would be kept, but the pageContext, together > > with the request, session and application would be used to store the da= ta > > model. Scalar, Hash and List wrappers would be made for all reasonable > Java > > objects, much like the current reflection code in contrib/reflection ar= ea. see above =20 > > * a custom taglib would be developed with syntax such as the following: > >=20 > > Scalar: > > <fm:scalar name=3D"customer.firstName"/> Perhaps we should mimic the freemarker ${..} syntax a bit. To display an element, use fm:show or something like that. =20 > > List: > > <fm:list select=3D"basket.products" as=3D"product"> > > <fm:scalar name=3D"product.name"/> <fm:scalar name=3D"product.price"/> > > </fm:list> Same here: <fm:foreach name=3D"basket.products" as=3D"product"> ... =20 > > I have not worked out the include, function, etc. syntax, but presumably > > we > > could either use the jsp mechanisms for those, or include our own > > implementation. <fm:include name=3D"/foo.tpl"/> (accessing a template from the template cache and <%@ include file=3D"foo.inc" %>=20 to use a static include from the jsp compiler. =20 > > If you did an <assign>, that would go into the pageContext, perhaps und= er > a > > special freemarker holding object that would also get checked. We could extend that: <fm:assign name=3D"foobar" scope=3D"application"/> (another page) <fm:show name=3D"application.foobar"/> =20 Would be a nice enhancement for Freemarker.=20 Since we are talking about some new functionality, has anybody tought about a persistent TemplateModel(Root) ? Cheers Holger --=20 Holger Arendt ar...@hs... | D=FCsseldorfer Linux User Gr= oup | http://www.dlug.de Java auf den Punkt gebracht: | --------------------------- http://www.classpath.de | PGP public key available |
From: Crane, D. <David.Crane@TMS.TM3.COM> - 2001-01-30 22:53:22
|
I do think that J2EE is catching on -- certainly it is where I work. EJBs seem to hold promise for writing distributed multi-tier systems. Scott Hasse's made a posting to this list about 7 weeks ago, with the subject "Freemarker-like jsp taglib", in which he discussed the possibility of using FreeMarker inside JSPs. Marius Scurtescu's article in the "FreeMarker Article on JavaWorld" thread floated the same idea. Is anyone working on something like this? There wasn't much response to Scott's posting in December, but people might have more thoughts today. Essentially, all the benefits of strict MVC and the TemplateModel could be preserved. Only the syntax of the HTML-precursor file needs to change -- instead of processing of template files with macros and freemarker tags, there would be a taglib of custom tags such as <fm:scalar> and <fm:list> that were based on use of the TemplateModel. The J2EE version of MVC (which Sun is calling Model 2) uses a servlet for the controller, a JSP for the view, and something like EJBs for the model. I think we all agree that putting snippets of Java code in JSP (I refuse to dignify them with the name "scriptlets") should be considered harmful. It would probably not take much servlet code to make the TemplateModel available to the JSP custom tags. It would be simple to wrap an EJB interface into TemplateModel nodes. These custom tags would be fairly intuitive for web designers (and eventually JSP development tools should also be trainable, too). Because the TemplateModel is also intuitive, a Java developer working on the backend should be able to document a model structure for use by a web designer working on the frontend. No Java code should ever be necessary in the JSP. David Crane ====================================================================== On Dec. 11, Scott Hasse (sco...@is...) wrote: > > Hi, all > > I am currently putting the finishing touches on a project which I started > with Freemarker and had to migrate to JSP due to customer standardization > issues. This situation has gotten me thinking about the tradeoffs and > benefits of Freemarker versus JSP. For the record, I am a big Freemarker > fan, and have used it successfully on several projects. > > Some things I like about Freemarker vs JSP: > > * I think the "Data Model" paradigm with the model being completely > represented as Scalar, Hash and List values really works well. > > * I think Freemarker does a much better job of drawing a clear line between > business objects and the presentation. > > * You cannot solve a problem in a quick and dirty (and ultimately bad) way > by putting Java code into a freemarker template. > > * The looping and conditional elements are elegant, and I believe easily > understood by html developers. > > Some things I like about JSP vs. Freemarker: > > * It is currently considered more "standard". I don't enjoy having to > explain/sell what Freemarker is to customers that already have JSP deployed. > Jason Hunter's "The Problems with JSP" (www.servlets.com) does a great job > of framing the issues, but there is still no conclusive solution to the > issues he raises. Also, WebMacro is mentioned there vs. Freemarker... > > * The syntax for anything complex (even looping) is very complex. Also, the > bean syntax is a bit contrived, in my opinion. > > * The taglib capability in JSP does allow custom syntax in a standard way. > > So, I have lately been wondering about trying to incorporate the good parts > of freemarker into a taglib for jsp. There are currently some taglib > efforts going on, but nothing I've seen has been even close to providing the > good aspects of Freemarker. So, here are my initial thoughts: > > * The "data model" paradigm would be kept, but the pageContext, together > with the request, session and application would be used to store the data > model. Scalar, Hash and List wrappers would be made for all reasonable Java > objects, much like the current reflection code in contrib/reflection area. > > * a custom taglib would be developed with syntax such as the following: > > Scalar: > <fm:scalar name="customer.firstName"/> > <fm:scalar name="date"/> > ..etc. > > List: > <fm:list select="basket.products" as="product"> > <fm:scalar name="product.name"/> <fm:scalar name="product.price"/> > </fm:list> > > Conditional: > <fm:if test="customer.firstName"/>Hello <fm:scalar > name="customer.firstName"/></fm:if> > etc. > > Note that xml structure makes if...else a bit cumbersome, but the xslt > choose...when syntax could be borrowed for something like: > > <fm:choose> > <fm:when test="customer.firstName">Hello <fm:scalar > name="customer.firstName"/></fm:when> > <fm:when test="customer.emailAddress">Hello <fm:scalar > name="customer.emailAddress"/></fm:when> > <fm:otherwise>Please login in</fm:otherwise> > </fm:choose> > > I have not worked out the include, function, etc. syntax, but presumably we > could either use the jsp mechanisms for those, or include our own > implementation. > > As I said before, the actual pageContext, request, session and application > objects would be used as the data model, so something like: > <fm:scalar name="customer.firstName"/> > would result in a getValue from the pageContext for the object "customer", > if that was null, then check the request, session, applicaiton, in that > order (the PageContext.findAttribute() method would do this quite nicely). > If you did an <assign>, that would go into the pageContext, perhaps under a > special freemarker holding object that would also get checked. > > If the object is not found, then a null value is used. However, if an > object is found, it is wrapped by a wrapper object so that it can be > accessed via the very simple scalar, hash or list methods. Any primitive > values would be wrapped as scalars. Collections, Iterators, Ennumerations, > Arrays and other such objects would be wrapped as Lists, and all other > objects would be wrapped with a generic wrapper that would act as a hash. > > So, if you wanted your html designers to be able to use the > "customer.firstName" scalar, you would simply put customer in (say, for > instance), the session. > > Clearly, there are still a bunch of open issues with this approach, but I > wanted to bounce these initial ideas off of the people on this list, and see > what they thought. The custom taglib creation is itself pretty > straightforward, and I think having a set of freemarker-like jsp tags would > go a long way toward addressing the problems so inherent with jsp. > > Thoughts? > > Scott |
From: <ar...@hs...> - 2001-01-27 13:22:02
|
=20 > since updating the Freemarker pages at sourceforge, I created > .... ARGH typo attack (need some coffee ;-) since updating the Freemarker pages at sourceforge isn=B4t that easy (scp .. brr), I created a Freemarker weblog at http://freemarker.manilasites.com to post news and as a way to discuss Freemarker. Sorry... %-) --=20 Holger Arendt ar...@hs... | D=FCsseldorfer Linux User Gr= oup | http://www.dlug.de Java auf den Punkt gebracht: | --------------------------- http://www.classpath.de | PGP public key available |
From: <ar...@hs...> - 2001-01-27 12:44:05
|
Hi List, since updating the Freemarker pages at sourceforge, I created a Freemarker weblog at http://freemarker.manilasites.com to post news and to way to discuss Freemarker. Just started to create the pages, so please wait a few days till all links are up and the news are in the right format. Anyway, if somebody wants to contribute or anything, just mail me! Cheers Holger --=20 Holger Arendt ar...@hs... | D=FCsseldorfer Linux User Gr= oup | http://www.dlug.de Java auf den Punkt gebracht: | --------------------------- http://www.classpath.de | PGP public key available |
From: <ar...@hs...> - 2001-01-27 10:36:23
|
Hi Vincent, Vincent DiBartolo writes: =20 > 1. "The examples were simplistic."=20 > 2. "There are 3rd party tag libraries to do iteration over collection= s."=20 Sorry, dude you started a holy war :-) =20 Seriously, if you compare product A and product B, you=B4ll allways get a number of people from both camps, that will bash you, because you didn=B4t cover their "favourite toy" in the right way ;-) Personally, I liked the article, since it showed a great number of people Freemarker=B4s features and that JSP isn=B4t the only way to create dynamic pages. Cheers Holger --=20 Holger Arendt ar...@hs... | D=FCsseldorfer Linux User Gr= oup | http://www.dlug.de Java auf den Punkt gebracht: | --------------------------- http://www.classpath.de | PGP public key available |