Greg,
Many thanks for the elaboration. In the 15+ hours between, I went to the
bookstore to see if there had been an update on Velocity. I thought I had
seen a recent publication, but it turned out to be the same book I purchased
five years ago. It is really a very poorly written book [Wiley, "Mastering
Apache Velocity"], but the only one that seems to be out there.
Since I could not determine whether the 'disconnect' was in Velocity or
between Velocity and Struts, I spent an hour reading about Struts1 and 2 --
which books did include a couple of pages on Velocity integration, but
nothing beyond what I had already deciphered.
The big problem was that I was not getting any log output. Finally, I began
to understand the dichotomy you were trying to explain as between server
content available in the Models associated with a Page and the Model
associated with the overall Blog Farm. The reason my code was not being hit
was that I had not selected the setup option relating to 'aggregated
statistics'. I thought that designating a blog to be used for the 'front
page' was all that was required. As you know, unless you select the
'aggregate' check mark, the SiteModel is 'out of scope' even though I was
using the configuration parameter to state that I wanted to use it. If
Velocity could have been coereced into providing any sort of decent
diagnostic other than "I'm not going to be rendering anything because I have
'null' on the right side of an assignment statement.", I probably could have
debugged my problems several hours earlier.
That said, once I was able to get to my code, the next 'fly in the soup'
turns out to be some of the other toolkits in use. [I won't tell you how
old I am, but let me say that I was teaching SQL tuning for performance
before some of the guys at Britton-Lee founded Sybase, and I have not seen
such a poor implementation of a jdbc driver as is used in Roller, for more
than twenty years.] Perfectly good SQL that MySQL knows how to handle
cannot be used through the JPA nonesense. So, I found where the
DriverManager let's me grab a hold of a Connection and am just dealing
directly with the database and getting back the results that I need. So,
finally, Velocity is finding a Collection that it can iterate to display the
results. Yes, I am just returning Strings where I should probably be
returning an object, but now that I am able to get something, I will go back
to see how some of the other code is operating in that regard.
----- Original Message -----
From: <[email protected]>
To: <[email protected]>
Sent: March 06, 2009 01:20 AM
Subject: RE: The Missing Manual
Terry,
I am no expert, but;
01. The site model really only applies to the front page as there are
methods that do not relate to individual weblogs.
02. In roller.properties, models/classes are made available by the
configs:
# Set of models to be made available for weblog page rendering
rendering.pageModels=\
org.apache.roller.weblogger.ui.rendering.model.PageModel,\
org.apache.roller.weblogger.ui.rendering.model.ConfigModel,\
org.apache.roller.weblogger.ui.rendering.model.UtilitiesModel,\
org.apache.roller.weblogger.ui.rendering.model.URLModel,\
org.apache.roller.weblogger.ui.rendering.model.MessageModel,\
org.apache.roller.weblogger.ui.rendering.model.CalendarModel,\
org.apache.roller.weblogger.ui.rendering.model.MenuModel
# Set of models to be made available for weblog feed rendering
rendering.feedModels=\
org.apache.roller.weblogger.ui.rendering.model.FeedModel,\
org.apache.roller.weblogger.ui.rendering.model.ConfigModel,\
org.apache.roller.weblogger.ui.rendering.model.UtilitiesModel,\
org.apache.roller.weblogger.ui.rendering.model.URLModel,\
org.apache.roller.weblogger.ui.rendering.model.MessageModel
# Set of models to be made available for weblog search rendering
rendering.searchModels=\
org.apache.roller.weblogger.ui.rendering.model.SearchResultsModel,\
org.apache.roller.weblogger.ui.rendering.model.ConfigModel,\
org.apache.roller.weblogger.ui.rendering.model.UtilitiesModel,\
org.apache.roller.weblogger.ui.rendering.model.URLModel,\
org.apache.roller.weblogger.ui.rendering.model.MessageModel,\
org.apache.roller.weblogger.ui.rendering.model.CalendarModel,\
org.apache.roller.weblogger.ui.rendering.model.MenuModel
# Set of models to be made available for weblog page *preview* rendering
# NOTE: this *does* have some differences between the pageModels
rendering.previewModels=\
org.apache.roller.weblogger.ui.rendering.model.PreviewPageModel,\
org.apache.roller.weblogger.ui.rendering.model.ConfigModel,\
org.apache.roller.weblogger.ui.rendering.model.UtilitiesModel,\
org.apache.roller.weblogger.ui.rendering.model.PreviewURLModel,\
org.apache.roller.weblogger.ui.rendering.model.MessageModel,\
org.apache.roller.weblogger.ui.rendering.model.CalendarModel,\
org.apache.roller.weblogger.ui.rendering.model.MenuModel
# Set of page models specifically for site-wide rendering
rendering.siteModels=\
org.apache.roller.weblogger.ui.rendering.model.SiteModel,\
org.apache.roller.weblogger.ui.rendering.model.PlanetModel
03. The servlets are the entry points, in PageServlet checkout the code
around line #374, which sets up the velocity context via the ModelLoader
classes for the main pages. If the Weblog is the frontpage the
rendering.siteModels are made available also.
04. The model classes in org.apache.roller.weblogger.ui.rendering.model
implement interface Model which has a method getModelName(), This this
is the name that you use in the templating.
eg : If you create a new MyModel (implementing Model), and then in
getModelName() return 'myModel'. Then in roller.properties add the class
MyModel:
# Set of models to be made available for weblog page rendering
rendering.pageModels=\
....
org.apache.roller.weblogger.ui.rendering.model.CalendarModel,\
org.apache.roller.weblogger.ui.rendering.model.MenuModel\
org.apache.roller.weblogger.ui.rendering.model.MyModel
Then in the templating you can use $myModel.getxxx
If you place your code in the SiteModel (getModelName() == 'site') then
you must use $site.getxxx and then in the PageServlet make sure the
rendering.siteModels are loaded for ALL weblogs. If your method myMethod
relates to the whole site then probably best to put it SiteModel, but if
you want to call it in a normal weblog it would be better to add it to the
PageModel and not load the SiteModel for all weblogs.
Hope this helps.
Cheers Greg
Terry Corbet <[email protected]>
05/03/2009 18:58
Please respond to
[email protected]
To
[email protected]
cc
Subject
RE: The Missing Manual
I guess my reply ought to be, "Thanks, so much", and, indeed, I am
very appreciative of your help, but can you help me understand:
01. Why would there be some restriction concerning what functionality
would be limted to what templates?
02. Assuming the architects have some idea concerning security, it
still must be the case that such a 'rule' is implemented somewhere in
a public API over which I, as someone wanting to use the API, need to
have control. Can you tell me where to find the 'hooks' and where to
read something to explain how to control them?
03. Did I get into such a restriction because I mistakenly thought
that I could just get by by adding functionality to SiteModel? Would
such a restriction to 'Front Page' go away if I took the additional
steps necessary to create an entirely new Model?
04. If myMethod is coded into the SiteModel and your suggestion is to
invoke it using Velocity's $model in lieu of $site, then I really need
to understand how/where the mapping between Velocity naming and Java
class naming takes place. Can you tell me where to find that?
Share our environment commitment - conserve resources and contribute to the
reduction of CO2 emissions by not printing the email unless absolutely
necessary to do so.
Any opinions expressed are those of the author, not Ricoh UK Ltd. This
communication does not constitute either offer or acceptance of any
contractually binding agreement. Such offer or acceptance must be
communicated in writing. It is the responsibility of the recipient to ensure
this email and attachments are free from computer viruses before use and the
sender accepts no responsibility or liability for any such computer viruses.
Ricoh UK Ltd. may monitor the content of emails sent and received via its
network for the purpose of ensuring compliance with its policies and
procedures. This communication contains information, which may be
confidential or privileged. The information is intended solely for the use
of the individual or entity named above. If you are not the intended
recipient, be aware that any disclosure, copying, distribution or use of the
contents of this information is prohibited. If you have received this
communication in error, please notify the sender immediately by return email
with a copy to [email protected] . Please contact us on +44 (0) 208
261 4000 if you need assistance.
Registered in England No: 473236
VAT No: GB524161280 =
