You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Dave Warnock <da...@yahoo.co.uk> on 2000/09/11 16:52:17 UTC
Division of MVC Tasks
Hi,
We have been discussing internally within Sundayta the various roles that
parts of the MVC architecture play. The result is that we are uncertain
about certain parts.
We think these issues are relevant to all template engines hence I am
posting this message separately to the JTemplater, WebMacro and Velocity
lists.
For most of these issues we can see that the work can be done in
a) the Model (ie what gets put into the context/parameters for the template)
b) tools available to the template designer (eg the way melati works with a
melati object in the contect which has render methods for data elements).
c) via the template language (I guess the way JSP would be used)
d) via a view layer to manipulate the model as it is put into the context.
Of course the solutions need to be generic beyond HTML. It may be that
different answers are appropriate for the various issues.
1. Formatting
Many data elements (pretty much everything other than Strings) needs
formatting and this formatting will vary from user to user. For example a
template will need to present dates in multiple formats for different users
(mm/dd/yy, dd.mm.yy etc), the same for numbers (123,456.00 or 123.456,00).
What is the best way to handle this formatting? The format may be decided by
the user (with the application keeping user preferences) or via the tools
(eg using the servlet API to determine the browser's locale).
2. Internationalisation
There has been a debate about picking different templates based on locale
naming (just as Java does for properties). But the data going into the
template may also need to be localized (so this is a little like formatting
only for strings and involves using different text rather than simply
changing delimiters). In a web application the localization may have been
decided by url, by browser locale or by user settings.
3. Security
Some elements might need to be hidden from some users. Such as bank account
details in a staff listing. Should we have multiple staff classes or should
the logic be elsewhere?
4. User Preferences
Suppose the user can pick which columns they see in a report. Which layer
implements this restriction and how?
You get the idea.
What do you think?
Dave
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Re: Division of MVC Tasks
Posted by Tim Joyce <ti...@hoop.co.uk>.
Rafal,
> > Integer id
> > (primary)
> > (displaylevel = detail)
> > (displayorder = 10);
>
> Looks like you have presentation attributes coupled together with data
definiton.
> Doesn't it create all sorts of flexibility problems?
not as yet, but I take your point.
> I must stay that I like XML much better than some custom invented format.
We
> can use xerces to do parsing and validation for us, and DOM is simple and
easy to use.
you are probably right, but I quite like the way you can 'see' the code that
will be built.
cheers
timj
Re: Division of MVC Tasks
Posted by David Warnock <da...@sundayta.co.uk>.
Rafal Krzewski wrote:
> Looks like you have presentation attributes coupled together with data definiton.
> Doesn't it create all sorts of flexibility problems?
Actually the presentation attributes are normally only used by the
melati admin application which provides basic data entry for all tables.
> I must stay that I like XML much better than some custom invented format. We
> can use xerces to do parsing and validation for us, and DOM is simple and easy to use.
We have discussed supporting XML for poem but it was not a big enough
itch at present for anyone. It would be simple to plug in.
Dave
Re: Division of MVC Tasks
Posted by Rafal Krzewski <Ra...@e-point.pl>.
Tim Joyce wrote:
> cool, sounds very similar to POEM except we don't use XML, but rather a java
> like syntax called a 'Data Structure Definition'. Here is an extract
> (defining the User table and the GroupMembership table).
>
> package org.melati.poem;
>
> table User
> (displayorder = 2010)
> (description = "A registered user of the database")
> (category = "User")
> (seqcached) {
>
> Integer id
> (primary)
> (displaylevel = detail)
> (displayorder = 10);
Looks like you have presentation attributes coupled together with data definiton.
Doesn't it create all sorts of flexibility problems?
I must stay that I like XML much better than some custom invented format. We
can use xerces to do parsing and validation for us, and DOM is simple and easy to use.
Rafal
Re: Division of MVC Tasks
Posted by Tim Joyce <ti...@hoop.co.uk>.
> > > I think a good place for handling permissions would be to add
> > > "readpermission" "insertpermission" and "updatepermission" attributes
to
> > > table and column elements in XLM schema (I am talking about
> > > Turbine/Torque here) and Torque would put appropriate permission check
> > > code into generated java sources.
> >
> > this is exactly what POEM does. You can use POEM outside of Melati, so
it
> > should be easy to integrate with Turbine (i think someone is working on
> > this). I don't know what Torque is, but it sounds a bit like POEM.
Does it
> > handle Persistence? How does it handle transactions? Is there a
mailing
> > list - I feel that I could contribute based on my POEM experience.
>
> The persistency layer in turbine is called 'Peers'. Torque is a tool that
> generates sql schemas for different DBs and soruces for Business Objects
> and their Peers (the classes that manage DB access for BOs) from an XML
> description of a DB.
cool, sounds very similar to POEM except we don't use XML, but rather a java
like syntax called a 'Data Structure Definition'. Here is an extract
(defining the User table and the GroupMembership table).
package org.melati.poem;
table User
(displayorder = 2010)
(description = "A registered user of the database")
(category = "User")
(seqcached) {
Integer id
(primary)
(displaylevel = detail)
(displayorder = 10);
String name (size = 60)
(displayname = "Full name")
(description = "The user's real name")
(displayorderpriority = 0)
(displaylevel = primary)
(searchability = primary)
(displayorder = 20)
(indexed);
String login
(size = 20)
(unique)
(displayorder = 30)
(description = "The user's login name");
Password password
(size = 20)
(description = "The user's password")
(displaylevel = record)
(displayorder = 40)
(searchability = no);
}
table GroupMembership
(displayorder = 2040)
(displayname = "Group membership")
(category = "User")
(description = "A record that a given user is a member of a given group")
{
Integer id
(displaylevel = detail)
(primary) ;
User user
(displayorderpriority = 0)
(displayname = "User")
(description = "The user who belongs to the group");
Group group
(displayorderpriority = 1)
(displayname = "Group")
(description = "The group to which the user belongs")
(searchability = primary);
}
cheers
timj
Re: Division of MVC Tasks
Posted by Rafal Krzewski <Ra...@e-point.pl>.
Tim Joyce wrote:
>
> Fedor,
>
> > I think a good place for handling permissions would be to add
> > "readpermission" "insertpermission" and "updatepermission" attributes to
> > table and column elements in XLM schema (I am talking about
> > Turbine/Torque here) and Torque would put appropriate permission check
> > code into generated java sources.
>
> this is exactly what POEM does. You can use POEM outside of Melati, so it
> should be easy to integrate with Turbine (i think someone is working on
> this). I don't know what Torque is, but it sounds a bit like POEM. Does it
> handle Persistence? How does it handle transactions? Is there a mailing
> list - I feel that I could contribute based on my POEM experience.
The persistency layer in turbine is called 'Peers'. Torque is a tool that
generates sql schemas for different DBs and soruces for Business Objects
and their Peers (the classes that manage DB access for BOs) from an XML
description of a DB.
Rafal.
Re: Division of MVC Tasks
Posted by Tim Joyce <ti...@hoop.co.uk>.
Fedor,
> I think a good place for handling permissions would be to add
> "readpermission" "insertpermission" and "updatepermission" attributes to
> table and column elements in XLM schema (I am talking about
> Turbine/Torque here) and Torque would put appropriate permission check
> code into generated java sources.
this is exactly what POEM does. You can use POEM outside of Melati, so it
should be easy to integrate with Turbine (i think someone is working on
this). I don't know what Torque is, but it sounds a bit like POEM. Does it
handle Persistence? How does it handle transactions? Is there a mailing
list - I feel that I could contribute based on my POEM experience.
cheers
timj
Re: Division of MVC Tasks
Posted by Fedor Karpelevitch <fe...@home.com>.
I think a good place for handling permissions would be to add
"readpermission" "insertpermission" and "updatepermission" attributes to
table and column elements in XLM schema (I am talking about
Turbine/Torque here) and Torque would put appropriate permission check
code into generated java sources.
"Geir Magnusson Jr." wrote:
>
> Travis Low wrote:
> >
> > Right, not a big deal, but I've been using Turbine Roles for this.
> > It's a natural fit. The application does a single "context.put" based
> > on the roles. Then you have:
> >
> > #if usertype == "administrator"
> > For admin eyes only
> > #end
>
> But this seems to mix the Model functionality in the View functionality,
> whereas it could be solved with the Controller specifying a different
> template, or use a frame-like template system where the Controller
> chooses the appropos content template, which gets included in a frame
> template with a #parse, decoupling the navigation / look from the
> content body or content body parts (addressing the 'skin' problem that
> floated by late last week..)
>
> I use the View to simply showing what the Controller-Model team decided
> to show.
>
> While I try not to be a stiff MVC ideologue, trying to stick to the
> spirit of MVC seems to have kept me out of serious trouble a few times.
>
> > > > 4. User Preferences
> > > >
> > > > Suppose the user can pick which columns they see in a report. Which layer
> > > > implements this restriction and how?
> > >
> > > In the template with a #foreach.
> >
> > That doesn't make sense to me. I think you'd have to add a "user
> > preferences" section to the application, then vary your context.put's
> > based on these preferences. It's not business logic, but it's not
> > template logic either.
>
> I agree. Similar arg to above.
>
> geir
> --
> Geir Magnusson Jr.
> geirm@optonline.com
--
Next generation of VB:
Microsoft (r) Visual Basic = Microsoft (r) Visual Basic + 1
Re: Division of MVC Tasks
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Travis Low wrote:
>
> Right, not a big deal, but I've been using Turbine Roles for this.
> It's a natural fit. The application does a single "context.put" based
> on the roles. Then you have:
>
> #if usertype == "administrator"
> For admin eyes only
> #end
But this seems to mix the Model functionality in the View functionality,
whereas it could be solved with the Controller specifying a different
template, or use a frame-like template system where the Controller
chooses the appropos content template, which gets included in a frame
template with a #parse, decoupling the navigation / look from the
content body or content body parts (addressing the 'skin' problem that
floated by late last week..)
I use the View to simply showing what the Controller-Model team decided
to show.
While I try not to be a stiff MVC ideologue, trying to stick to the
spirit of MVC seems to have kept me out of serious trouble a few times.
> > > 4. User Preferences
> > >
> > > Suppose the user can pick which columns they see in a report. Which layer
> > > implements this restriction and how?
> >
> > In the template with a #foreach.
>
> That doesn't make sense to me. I think you'd have to add a "user
> preferences" section to the application, then vary your context.put's
> based on these preferences. It's not business logic, but it's not
> template logic either.
I agree. Similar arg to above.
geir
--
Geir Magnusson Jr.
geirm@optonline.com
Re: Division of MVC Tasks
Posted by Marc Palmer <ma...@anyware.co.uk>.
> My rule: If you want to restrict access to data and stake your reputation
> on it, don't give anyone else they key to unlock the data ;-)
Just thought I'd apologise for all the typos in that previous message. It
was a bit early for me. :-)
Re: Division of MVC Tasks
Posted by Christoph Reck <Ch...@dlr.de>.
yes, this seems to be the right approach.
The configurable formatter presented by me previously in this thread
provides the flexibility of allowing the page designers to generate
the view portion of the objects, the controller controls the used
formatter (e.g. for dates or currencies) via configuration.
By subclassing/implementing the formatter configuration dispatcher,
it could be enhanced with different presentation coding depending
on the authorization level. This simplifies greatly the top-level
templates (which then can be independent of the authorization/user).
Cheers,
Christoph
Marc Palmer wrote:
>
> I'm with you Tim. My current system is separated like most systems we're
> all developing... :
>
> Data Layer
> ----------
> Servlet
> ----------
> Templates
>
> Now, the Servlet loads/saves to/from the Data Layer. However it will not
> pass data to the Templates (via the Context) unless the viewer has
> EXPLICIT access to it. Therefore there is not way at all that private
> data can appear on a web page accessed by an unauthorised user.
>
> Access restriction in the templates is far from ideal IMO. Security of
> this data is of utmost imporance - we can't spend months working on a
> system and tell our managers' "it is completely secure" only to find that
> some dumbass changes the template later and lets all the sensitive
> information out to the world with nobody realising.
>
> My rule: If you want to restrict access to data and stake your reputation
> on it, don't give anyone else they key to unlock the data ;-)
>
> Cheers
Re: Division of MVC Tasks
Posted by Marc Palmer <ma...@anyware.co.uk>.
------ Original Message ------
On 12/09/00, 07:16:47, Tim Joyce <ti...@hoop.co.uk> wrote regarding Re:
Division of MVC Tasks:
> > Right, not a big deal, but I've been using Turbine Roles for this.
> > It's a natural fit. The application does a single "context.put" based
> > on the roles. Then you have:
> >
> > #if usertype == "administrator"
> > For admin eyes only
> > #end
> umm, i would not trust template designers with security issues (you may
not
> even know them - see previous thread re #while), but rather put security
at
> a low level, as the data comes out of the db. eg melati (POEM) can throw
an
> AccessExceptoin on
> $object.getField()
> so there is now way to get the data unless you have permission. This
also
> mitagates against sloppy servlet programmers (and there are plenty of
those
> :).
I'm with you Tim. My current system is separated like most systems we're
all developing... :
Data Layer
----------
Servlet
----------
Templates
Now, the Servlet loads/saves to/from the Data Layer. However it will not
pass data to the Templates (via the Context) unless the viewer has
EXPLICIT access to it. Therefore there is not way at all that private
data can appear on a web page accessed by an unauthorised user.
Access restriction in the templates is far from ideal IMO. Security of
this data is of utmost imporance we can't spend months working on a
system and tell our managers' "it is completely secure" only to find that
some dumbass changes the template later and lets all the sensitive
information out to the world with nobody realising.
My rule: If you want to restrict access to data and stake your reputation
on it, don't give anyone else they key to unlock the data ;-)
Cheers
Re: Division of MVC Tasks
Posted by Tim Joyce <ti...@hoop.co.uk>.
Jon,
> > sure, but if security is in the template, the designers can just remove
> > (accedentally or deliberately) whatever the engineers have added, and
then
> > they expose all that valuable data.
>
> I'm not sure I believe that some template designer who has been explicitly
> taught to not remove things is going to just "accidentally" remove
> something. I want to give designers a bit more credit than that.
fair play, but it then becomes difficult to assume responsibility for the
security of the system. I like to give an assurance to my customers (who
may be using our designers, a third party or their own) that the system is
as secure as I can make it.
> > <table>
> > <tr><td>Tim</td><td>Withheld (click <a href=login.html>here</a> to
> > login)</td></tr>
> > </table>
>
> Ok, I'm not trying to argue with you,
not at all, its genuinely nice for someone to take an interest :)
> but I'm still a bit fuzzy on this so
> please be patient with me.
>
> I don't understand how you are going to get to the point where you have
the
> last chunk of HTML below.
>
> In other words...if you get an AccessException, then how do you catch that
> in your template in order to display alternate output?
Using webmacro, we have hacked Variable.java to propegate the exception
which we then catch when we expand the template. It's all a bit messy at
the moment, but we are WIP with tidying it up. Have you been following the
thread on exceptions on the WM list? This will help us. Here is some code
you could look at:
http://www.paneris.org/cgi-bin/cvsweb.cgi/org/webmacro/engine/Variable.java
http://www.paneris.org/cgi-bin/cvsweb.cgi/org/melati/MelatiWMServlet.java
http://www.paneris.org/cgi-bin/cvsweb.cgi/org/melati/MelatiServlet.java
http://www.paneris.org/cgi-bin/cvsweb.cgi/org/melati/Melati.java
http://www.paneris.org/cgi-bin/cvsweb.cgi/org/melati/templets/html/java.lang
.Exception.wm
> You don't give an
> example of that, you only show what *could* be the result of catching that
> exception.
>
> As far as I can tell, your idea is sound, but your implementation is not.
it does actually work, please go to
http://5789.paneris.org (in development :) and do a search for say 'Jon'
(sorry for the slow response :)
you can see that the tel no and email address are not available to not
loggedin users. This is achieved in the templates by putting:
#set $onVariableException = $melati.PassbackVariableExceptionHandler
without this, the user would be redirected to the login page.
>
> > not at all. no markup should appear outside of templates (templets).
>
> Ok, then how are you going to catch an exception in your template and
> display alternative text? Show me a concrete implementation of the
examples
> above.
I hope this helps. I am happy to answer more questions.
cheers
timj
Re: Division of MVC Tasks
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/12/2000 12:35 AM, "Tim Joyce" <ti...@hoop.co.uk> wrote:
> sure, but if security is in the template, the designers can just remove
> (accedentally or deliberately) whatever the engineers have added, and then
> they expose all that valuable data.
I'm not sure I believe that some template designer who has been explicitly
taught to not remove things is going to just "accidentally" remove
something. I want to give designers a bit more credit than that.
> the html table itself has no value, so doesn't need to be secure, however
> the data does.
>
> so imagine you wanted to do the following:
>
> <table>
> #foreach $user in $users #begin
> <tr><td>$user.Name</td><td>$user.BankAccountNumber</td></tr>
> #end
> </table>
>
> you would apply restructions to your user.getBankAccountNumber() method.
> This would throw an AccessException (if the current users does not have
> appropiate permissions). This exception can be caught, and the user
> redirected to a login page, or an appropiate message can be displayed inline
> (eg):
>
> <table>
> <tr><td>Tim</td><td>Withheld (click <a href=login.html>here</a> to
> login)</td></tr>
> </table>
Ok, I'm not trying to argue with you, but I'm still a bit fuzzy on this so
please be patient with me.
I don't understand how you are going to get to the point where you have the
last chunk of HTML below.
In other words...if you get an AccessException, then how do you catch that
in your template in order to display alternate output? You don't give an
example of that, you only show what *could* be the result of catching that
exception.
As far as I can tell, your idea is sound, but your implementation is not.
> not at all. no markup should appear outside of templates (templets).
Ok, then how are you going to catch an exception in your template and
display alternative text? Show me a concrete implementation of the examples
above.
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
Re: Division of MVC Tasks
Posted by Tim Joyce <ti...@hoop.co.uk>.
> > umm, i would not trust template designers with security issues
>
> Uh, I think you have missed the point of the separation and who does what
> job. Engineers still touch the templates and can add security into them,
the
> template designers are just supposed to be smart enough to take an
existing
> template and work with it or create a new template. It can still be the
> engineers who add the security to things.
sure, but if security is in the template, the designers can just remove
(accedentally or deliberately) whatever the engineers have added, and then
they expose all that valuable data.
>
> > (you may not
> > even know them - see previous thread re #while), but rather put security
at
> > a low level, as the data comes out of the db. eg melati (POEM) can
throw an
> > AccessExceptoin on
> >
> > $object.getField()
> >
> > so there is now way to get the data unless you have permission. This
also
> > mitagates against sloppy servlet programmers (and there are plenty of
those
> > :).
>
> What if you are showing and hiding an entire html table of data in a page?
the html table itself has no value, so doesn't need to be secure, however
the data does.
so imagine you wanted to do the following:
<table>
#foreach $user in $users #begin
<tr><td>$user.Name</td><td>$user.BankAccountNumber</td></tr>
#end
</table>
you would apply restructions to your user.getBankAccountNumber() method.
This would throw an AccessException (if the current users does not have
appropiate permissions). This exception can be caught, and the user
redirected to a login page, or an appropiate message can be displayed inline
(eg):
<table>
<tr><td>Tim</td><td>Withheld (click <a href=login.html>here</a> to
login)</td></tr>
</table>
>
> Are you expecting to say $object.getTable() and have it return HTML? Seems
> like the wrong way to do security to me.
not at all. no markup should appear outside of templates (templets).
timj
Re: Division of MVC Tasks
Posted by David Warnock <da...@sundayta.co.uk>.
Jon,
I agree with Tim, security should not appear in the template. There are
3 main problems
- too error prone (too easy to accidently get wrong)
- could open potential security holes (if someone could upload a
template or possibly put template commands in a form they upload).
- Will make templates longer and more complex when there are multiple
roles involved in a page
- Makes maintenance of roles complex requiring too much editing in too
many places.
Dave
Re: Division of MVC Tasks
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/11/2000 11:16 PM, "Tim Joyce" <ti...@hoop.co.uk> wrote:
> umm, i would not trust template designers with security issues
Uh, I think you have missed the point of the separation and who does what
job. Engineers still touch the templates and can add security into them, the
template designers are just supposed to be smart enough to take an existing
template and work with it or create a new template. It can still be the
engineers who add the security to things.
> (you may not
> even know them - see previous thread re #while), but rather put security at
> a low level, as the data comes out of the db. eg melati (POEM) can throw an
> AccessExceptoin on
>
> $object.getField()
>
> so there is now way to get the data unless you have permission. This also
> mitagates against sloppy servlet programmers (and there are plenty of those
> :).
What if you are showing and hiding an entire html table of data in a page?
Are you expecting to say $object.getTable() and have it return HTML? Seems
like the wrong way to do security to me.
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
Re: Division of MVC Tasks
Posted by Tim Joyce <ti...@hoop.co.uk>.
> > > 3. Security
> > >
> > > Some elements might need to be hidden from some users. Such as bank
account
> > > details in a staff listing. Should we have multiple staff classes or
should
> > > the logic be elsewhere?
> >
> > What is wrong with:
> >
> > #if ($data.ACL.hasPermission("Foo"))
> > some foo stuff here!
> > #end
> >
> > Then it is up to the template designer to help with security. Not a big
> > deal.
>
> Right, not a big deal, but I've been using Turbine Roles for this.
> It's a natural fit. The application does a single "context.put" based
> on the roles. Then you have:
>
> #if usertype == "administrator"
> For admin eyes only
> #end
umm, i would not trust template designers with security issues (you may not
even know them - see previous thread re #while), but rather put security at
a low level, as the data comes out of the db. eg melati (POEM) can throw an
AccessExceptoin on
$object.getField()
so there is now way to get the data unless you have permission. This also
mitagates against sloppy servlet programmers (and there are plenty of those
:).
cheers
timj
Re: Division of MVC Tasks
Posted by David Warnock <da...@sundayta.co.uk>.
Jon Stevens wrote:
> <table>
> #foreach $row in $allRows
> <tr>
> #if ($prefs.hasColumn(1))
> <td>Column 1</td>
> #end
> #if ($prefs.hasColumn(2))
> <td>Column 2</td>
> #end
> </tr>
> #end
> </table>
>
> That sounds like perfect MVC to me.
And it's a good example of why simple maths is needed. Tables often have
extra headings that span multiple columns. Using a template variable
allows you to do this
#set heading1width = 0
#if ($prefs.hasColumn(1))
#set heading1width++
#end
#if ($prefs.hasColumn(2))
#set heading1width++
#end
then you can use heading1width in colspan and cols parameters for the
table.
Dave
Re: Division of MVC Tasks
Posted by Fedor Karpelevitch <fe...@home.com>.
I thought about it a little more and think now that your way is actually
better. Are you going to work on implementing this? If so I'd like to
help you. I also think that "formatter" does not reflect all the
meaning. Any better name? "Processor" ?
Christoph Reck wrote:
>
> I disagree in require implementing an interface for each object.
> The way to go should be more like the BeanInfo approach.
>
> A configuration file providing the mapping between objects and
> the formatter should exist (e.g. with an HTMLable interface). This can
> then be used by the formatter:
> [formatters]
> java.lang.Date = org.xxx.yyy.DateHTMLer
> ...
> default = org.apache.velocity.templateFormatter
> The access to this configuration can be inherited (implemented
> if its defined as an interface) and provide propietary means of
> access (e.g. from a DB according to user preferences).
>
> Finally the formatter (to HTML or anythig else) could use a
> hard coded class, Otherwise (as default) a velocity provided
> formatter (based on file mapping of the class name) using a
> template which accesses the object to be formatted! If no
> template is found, then it uses toString().
>
> OK, you could implement the HTMLable interface on your abjects as
> well, then the "beans" are complete. If the conf. lookup fails, it
> could resort firstly to reflection to see if your class implements
> the formatter interface, otherwise it would use the velocity
> default formatter.
>
> this is my 2c!
>
> Please give me feedback if I should proceed implementing this!
>
> Cheers,
> Christoph
>
> Fedor Karpelevitch wrote:
> >
> > Hi!
> >
> > I was thinking on this subject lately as well and I do not think that
> > Format functions are nice... That's a first step to the Pages That Suck.
> > An idea I have is to use types to handle this sort of stuff. Let me
> > explain. Let's make all methods return result of some interface (say
> > HTMLable) this interface would have single method:
> > <code>public String toHTML(WebContext wc);</code>
> > (not sure if you need to pass the context, but may be useful)
> > Here is how it works:
> > we need a set of classes implementing this interface, such as:
> >
> > <code>public class ComboBox extends Vector implements HTMLable </code>
> > toHTML should generate <SELECT><OPTION>....</SELECT>
> >
> > <code>public class Money extends Float implements HTMLable </code>
> > toHTML should return money-formatted string. It can probably pick-up the
> > format info from the context.
> >
> > etc..
> >
> > (in the case when the object does not implement HTMLable we should
> > probably fall back to using toString)
> >
> > so the business class should simply create the appropriate object and
> > stuff the data into it. And it would not need to mess with any HTML or
> > other presentation stuff. On the other hand the template will not need
> > to hard-code the formatting and loops which do not really belong there.
> > I would call this layer something like "Presentation Logic".
> > It also creates some new possibilities:
> >
> > 1) customization is seamless: if you format currency using smth. like
> > $format.money() what would you do if you need to change the format? What
> > if you need to make it user-configurable? With my suggestion you would
> > simply change "MoneyFormat" in the context an you are ready to go.
>
> exactly this gets fixed with my recommended aproach above.
>
> >
> > 2) suppose you want to show a value on the screen in an input box or as
> > text depending on whether the user has the right to edit it. You would
> > probably have to do:
> > <code>
> > #if $user.hasPermission("bla")
> > <INPUT type=text ....value='$bla.bla'>
> > #else
> > $bla.bla
> > #endif
> > </code>
> > not very nice for a template.... (I also agree that template is the
> > worst place to check permissions).
> >
> > MyWay you'd simply have:
> >
> > <code>
> > $bla.bla
> > </code>
> >
> > and you'd simply have to provide object of the appropriate class, say
> > InputBox and PlainText. Or even better: create InputboxBox in either
> > case, but set Readonly property to true:
> >
> > <code>
> > InputBox blaBla = new InputBox("bla_bla");
> > InputBox.setValue(12345);
> > InputBox.setReadonly(!user.hasPermission("bla"))
> > </code>
> >
> > InputBox with Readonly set to true would output "<INPUT type=text
> > READONLY.." for browsers which support it and plain text for those who
> > do not (it could know the browser from the context).
> >
> > These are just thoughts. I hope I am not reinventing the wheel.
> >
> > WBR, Fedor.
--
Next generation of VB:
Microsoft(r) Visual Basic = Microsoft(r) Visual Basic + 1
Re: Division of MVC Tasks
Posted by Christoph Reck <Ch...@dlr.de>.
I disagree in require implementing an interface for each object.
The way to go should be more like the BeanInfo approach.
A configuration file providing the mapping between objects and
the formatter should exist (e.g. with an HTMLable interface). This can
then be used by the formatter:
[formatters]
java.lang.Date = org.xxx.yyy.DateHTMLer
...
default = org.apache.velocity.templateFormatter
The access to this configuration can be inherited (implemented
if its defined as an interface) and provide propietary means of
access (e.g. from a DB according to user preferences).
Finally the formatter (to HTML or anythig else) could use a
hard coded class, Otherwise (as default) a velocity provided
formatter (based on file mapping of the class name) using a
template which accesses the object to be formatted! If no
template is found, then it uses toString().
OK, you could implement the HTMLable interface on your abjects as
well, then the "beans" are complete. If the conf. lookup fails, it
could resort firstly to reflection to see if your class implements
the formatter interface, otherwise it would use the velocity
default formatter.
this is my 2c!
Please give me feedback if I should proceed implementing this!
Cheers,
Christoph
Fedor Karpelevitch wrote:
>
> Hi!
>
> I was thinking on this subject lately as well and I do not think that
> Format functions are nice... That's a first step to the Pages That Suck.
> An idea I have is to use types to handle this sort of stuff. Let me
> explain. Let's make all methods return result of some interface (say
> HTMLable) this interface would have single method:
> <code>public String toHTML(WebContext wc);</code>
> (not sure if you need to pass the context, but may be useful)
> Here is how it works:
> we need a set of classes implementing this interface, such as:
>
> <code>public class ComboBox extends Vector implements HTMLable </code>
> toHTML should generate <SELECT><OPTION>....</SELECT>
>
> <code>public class Money extends Float implements HTMLable </code>
> toHTML should return money-formatted string. It can probably pick-up the
> format info from the context.
>
> etc..
>
> (in the case when the object does not implement HTMLable we should
> probably fall back to using toString)
>
> so the business class should simply create the appropriate object and
> stuff the data into it. And it would not need to mess with any HTML or
> other presentation stuff. On the other hand the template will not need
> to hard-code the formatting and loops which do not really belong there.
> I would call this layer something like "Presentation Logic".
> It also creates some new possibilities:
>
> 1) customization is seamless: if you format currency using smth. like
> $format.money() what would you do if you need to change the format? What
> if you need to make it user-configurable? With my suggestion you would
> simply change "MoneyFormat" in the context an you are ready to go.
exactly this gets fixed with my recommended aproach above.
>
> 2) suppose you want to show a value on the screen in an input box or as
> text depending on whether the user has the right to edit it. You would
> probably have to do:
> <code>
> #if $user.hasPermission("bla")
> <INPUT type=text ....value='$bla.bla'>
> #else
> $bla.bla
> #endif
> </code>
> not very nice for a template.... (I also agree that template is the
> worst place to check permissions).
>
> MyWay you'd simply have:
>
> <code>
> $bla.bla
> </code>
>
> and you'd simply have to provide object of the appropriate class, say
> InputBox and PlainText. Or even better: create InputboxBox in either
> case, but set Readonly property to true:
>
> <code>
> InputBox blaBla = new InputBox("bla_bla");
> InputBox.setValue(12345);
> InputBox.setReadonly(!user.hasPermission("bla"))
> </code>
>
> InputBox with Readonly set to true would output "<INPUT type=text
> READONLY.." for browsers which support it and plain text for those who
> do not (it could know the browser from the context).
>
> These are just thoughts. I hope I am not reinventing the wheel.
>
> WBR, Fedor.
Re: Division of MVC Tasks
Posted by Fedor Karpelevitch <fe...@home.com>.
Hi!
I was thinking on this subject lately as well and I do not think that
Format functions are nice... That's a first step to the Pages That Suck.
An idea I have is to use types to handle this sort of stuff. Let me
explain. Let's make all methods return result of some interface (say
HTMLable) this interface would have single method:
<code>public String toHTML(WebContext wc);</code>
(not sure if you need to pass the context, but may be useful)
Here is how it works:
we need a set of classes implementing this interface, such as:
<code>public class ComboBox extends Vector implements HTMLable </code>
toHTML should generate <SELECT><OPTION>....</SELECT>
<code>public class Money extends Float implements HTMLable </code>
toHTML should return money-formatted string. It can probably pick-up the
format info from the context.
etc..
(in the case when the object does not implement HTMLable we should
probably fall back to using toString)
so the business class should simply create the appropriate object and
stuff the data into it. And it would not need to mess with any HTML or
other presentation stuff. On the other hand the template will not need
to hard-code the formatting and loops which do not really belong there.
I would call this layer something like "Presentation Logic".
It also creates some new possibilities:
1) customization is seamless: if you format currency using smth. like
$format.money() what would you do if you need to change the format? What
if you need to make it user-configurable? With my suggestion you would
simply change "MoneyFormat" in the context an you are ready to go.
2) suppose you want to show a value on the screen in an input box or as
text depending on whether the user has the right to edit it. You would
probably have to do:
<code>
#if $user.hasPermission("bla")
<INPUT type=text ....value='$bla.bla'>
#else
$bla.bla
#endif
</code>
not very nice for a template.... (I also agree that template is the
worst place to check permissions).
MyWay you'd simply have:
<code>
$bla.bla
</code>
and you'd simply have to provide object of the appropriate class, say
InputBox and PlainText. Or even better: create InputboxBox in either
case, but set Readonly property to true:
<code>
InputBox blaBla = new InputBox("bla_bla");
InputBox.setValue(12345);
InputBox.setReadonly(!user.hasPermission("bla"))
</code>
InputBox with Readonly set to true would output "<INPUT type=text
READONLY.." for browsers which support it and plain text for those who
do not (it could know the browser from the context).
These are just thoughts. I hope I am not reinventing the wheel.
WBR, Fedor.
Re: Division of MVC Tasks
Posted by Travis Low <tr...@dawnstar.org>.
Jon Stevens wrote:
> > There's filtering, locale, formatting, and possibly other issues. Perhaps
> > it's
> > time for MV^nC? (I tried and failed to find the MVC+1 I remember seeing a few
> > months ago -- is that relevant?)
>
> Turbine is Model 2 + 1, not MVC+1. What isn't clear about that?
Nothing, now. Thanks! I just visited
http://www.javaworld.com/javaworld/jw-12-1999/jw-12-ssj-jspmvc.html
It's a scream. Did you know that "the biggest advantage of using JSP is that it
helps effectively separate presentation from content"?
-- Travis Low
<ma...@dawnstar.org>
<http://dawnstar.org/travis>
Re: Division of MVC Tasks
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/11/2000 9:47 PM, "Travis Low" <tr...@dawnstar.org> wrote:
> Could you elaborate? I was thinking of a "format" subtree somewhere in
> Turbine,
> but Velocity does seem a better choice. I had this idea after I did a FM
> CalendarMonth -- I realized it wouldn't take much effort to make it generic.
> Still need to port it to WM, though.
Sure, move everything in org.apache.turbine.util.webmacro into Velocity and
make them things that are "default" context objects. I like Justin's idea of
ContextTool, but I'm not sure I like the implementations.
> I'm starting to think that MVC is too coarse a model, thus the confusion.
Actually I disagree: The confusion is around the fact that no one has been
building MVC apps yet. Perl CGI's are about as far as you can get from MVC.
Straight Servlets are a step up from Perl, but still very non-MVC. PHP is
about as bad as mod_perl except the language is slightly better for web
stuff IMHO.
We are now at edge of the next generation of tools which is combining
Servlets and getting all the benefits of using Servlets (truly cross
platform being a very strong case) as well as template languages like
Velocity which define the separation in the entire MVC train of thought.
Because this stuff is new for people, it will take some more time to catch
on. I can't wait to see where we are at in another year with the TDK being
stable and people building apps on top of it. :-)
> There's filtering, locale, formatting, and possibly other issues. Perhaps
> it's
> time for MV^nC? (I tried and failed to find the MVC+1 I remember seeing a few
> months ago -- is that relevant?)
Turbine is Model 2 + 1, not MVC+1. What isn't clear about that?
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
Re: Division of MVC Tasks
Posted by Travis Low <tr...@dawnstar.org>.
Jon Stevens wrote:
>
> >> In the template with a #foreach.
> > [travis is confused...]
>
> Ok, lets try an example:
>
> [spiffy example]
>
> That sounds like perfect MVC to me.
Yup, but funny -- I would have said "with an #if".
> I'm starting to think that we *really* need the following:
>
> * A set of Context objects that are as well defined and useful as the
> classes in the JDK. They can live either in Turbine or Velocity. I'm
> starting to feel that they should live in Velocity.
Could you elaborate? I was thinking of a "format" subtree somewhere in Turbine,
but Velocity does seem a better choice. I had this idea after I did a FM
CalendarMonth -- I realized it wouldn't take much effort to make it generic.
Still need to port it to WM, though.
> * A lot more examples of how to build MVC applications. I think that a lot
> of this confusion relates to the fact that not many of us (including
> myself!) are used to building applications that are 100% MVC.
I'm starting to think that MVC is too coarse a model, thus the confusion.
There's filtering, locale, formatting, and possibly other issues. Perhaps it's
time for MV^nC? (I tried and failed to find the MVC+1 I remember seeing a few
months ago -- is that relevant?)
-- Travis Low
<ma...@dawnstar.org>
<http://dawnstar.org/travis>
Re: Division of MVC Tasks
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/11/2000 12:38 PM, "Travis Low" <tr...@dawnstar.org> wrote:
> I agree with Jon, but I would add that resource bundles could be
> useful here. For formatting of individual data items, you could allow
> the user to select the format from a list of locales + a list of
> custom formats. Default to browser locale.
Actually, there is a TurbineLocalizationService that is a nice wrapper
around RB's. I would suggest using that.
>>> 4. User Preferences
>>>
>>> Suppose the user can pick which columns they see in a report. Which layer
>>> implements this restriction and how?
>>
>> In the template with a #foreach.
>
> That doesn't make sense to me. I think you'd have to add a "user
> preferences" section to the application, then vary your context.put's
> based on these preferences. It's not business logic, but it's not
> template logic either.
Ok, lets try an example:
<table>
#foreach $row in $allRows
<tr>
#if ($prefs.hasColumn(1))
<td>Column 1</td>
#end
#if ($prefs.hasColumn(2))
<td>Column 2</td>
#end
</tr>
#end
</table>
That sounds like perfect MVC to me.
I'm starting to think that we *really* need the following:
* A set of Context objects that are as well defined and useful as the
classes in the JDK. They can live either in Turbine or Velocity. I'm
starting to feel that they should live in Velocity.
* A lot more examples of how to build MVC applications. I think that a lot
of this confusion relates to the fact that not many of us (including
myself!) are used to building applications that are 100% MVC.
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
Re: Division of MVC Tasks
Posted by Travis Low <tr...@dawnstar.org>.
Jon Stevens wrote:
> on 9/11/2000 7:52 AM, "Dave Warnock" <da...@yahoo.co.uk> wrote:
>
> > 1. Formatting
> > 2. Internationalisation
I agree with Jon, but I would add that resource bundles could be
useful here. For formatting of individual data items, you could allow
the user to select the format from a list of locales + a list of
custom formats. Default to browser locale.
> > 3. Security
> >
> > Some elements might need to be hidden from some users. Such as bank account
> > details in a staff listing. Should we have multiple staff classes or should
> > the logic be elsewhere?
>
> What is wrong with:
>
> #if ($data.ACL.hasPermission("Foo"))
> some foo stuff here!
> #end
>
> Then it is up to the template designer to help with security. Not a big
> deal.
Right, not a big deal, but I've been using Turbine Roles for this.
It's a natural fit. The application does a single "context.put" based
on the roles. Then you have:
#if usertype == "administrator"
For admin eyes only
#end
> > 4. User Preferences
> >
> > Suppose the user can pick which columns they see in a report. Which layer
> > implements this restriction and how?
>
> In the template with a #foreach.
That doesn't make sense to me. I think you'd have to add a "user
preferences" section to the application, then vary your context.put's
based on these preferences. It's not business logic, but it's not
template logic either.
-- Travis Low
<ma...@dawnstar.org>
<http://dawnstar.org/travis>
Re: Division of MVC Tasks
Posted by Jon Stevens <jo...@latchkey.com>.
on 9/11/2000 7:52 AM, "Dave Warnock" <da...@yahoo.co.uk> wrote:
> 1. Formatting
>
> Many data elements (pretty much everything other than Strings) needs
> formatting and this formatting will vary from user to user. For example a
> template will need to present dates in multiple formats for different users
> (mm/dd/yy, dd.mm.yy etc), the same for numbers (123,456.00 or 123.456,00).
> What is the best way to handle this formatting? The format may be decided by
> the user (with the application keeping user preferences) or via the tools
> (eg using the servlet API to determine the browser's locale).
Simple:
$format.money("123,456.00")
Then, it is up to either the format object to pass the value through or for
it to format it.
The problem with the above is that there are few cases where the value of
the money will be static in the template, so the above would actually look
something like this:
#foreach $change in $myMoney
$format.money($change)
#end
> 2. Internationalisation
>
> There has been a debate about picking different templates based on locale
> naming (just as Java does for properties). But the data going into the
> template may also need to be localized (so this is a little like formatting
> only for strings and involves using different text rather than simply
> changing delimiters). In a web application the localization may have been
> decided by url, by browser locale or by user settings.
I like the index.en.vm idea quite a bit. The problem with localization and
formatting hasn't been solved yet. In other words, there is a problem with
the idea that a page designer builds something in english and expects the
same page layout to work in japanese. Not going to happen. Thus, having
different templates for doing the formatting would be very good IMHO even if
it means a lot of duplication. I think that is part of the price you pay for
internationalization.
> 3. Security
>
> Some elements might need to be hidden from some users. Such as bank account
> details in a staff listing. Should we have multiple staff classes or should
> the logic be elsewhere?
What is wrong with:
#if ($data.ACL.hasPermission("Foo"))
some foo stuff here!
#end
Then it is up to the template designer to help with security. Not a big
deal.
> 4. User Preferences
>
> Suppose the user can pick which columns they see in a report. Which layer
> implements this restriction and how?
In the template with a #foreach.
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/