JSTL - Following MVC

[Christine Mayer]

Hi, I've got a J2EE application (trying) to follow the MVC paradigm.
So far, there is a data model, which is sent to the view. The view
then calls java functions to html formate Strings from this model,
using inline java code, which I don't like very much. Would you:
a) leave it as it is
for: No work to do
against:Mixes JSTL tags with java inline code - ugly
b) add an additional "view-model" attribute for each attribute to be
displayed on the view, that already contains the necessary html style
informations
for: No more logic (java inline code) in the jsps
against: each attribute exists in 2 varieties in one hugh model

c) Add another view-model, and map from data-model to view model in a
huge loop before displaying the view model on the view?
pro: Data-model and view-model are totally separated, no more logic in
the jsps
against: lots of programming to do, and mapping all attributes from
one model to the other model would cost a lot of performance.

d) Simply add new getter methods for each attribute to the current
data-model.
So e.g. there would be a getName() method to get the data
representation of the name, and getFormatedName() which would first
call getName and then manipulate the name attribute to get a view
representation of it.
pro No more logic in the jsps, beans will not be "flooded" by
"duplicate attributes"
contra: Data model would still contain view-model getter methods.

Thanks for your advice,

Christine

 

[david.karr]

Hi, I've got a J2EE application (trying) to follow the MVC paradigm.
So far, there is a data model, which is sent to the view. The view
then calls java functions to html formate Strings from this model,
using inline java code, which I don't like very much. Would you:
a) leave it as it is
for: No work to do
against:Mixes JSTL tags with java inline code - ugly
b) add an additional "view-model" attribute for each attribute to be
displayed on the view, that already contains the necessary html style
informations
for: No more logic (java inline code) in the jsps
against: each attribute exists in 2 varieties in one hugh model

c) Add another view-model, and map from data-model to view model in a
huge loop before displaying the view model on the view?
pro: Data-model and view-model are totally separated, no more logic in
the jsps
against: lots of programming to do, and mapping all attributes from
one model to the other model would cost a lot of performance.

d) Simply add new getter methods for each attribute to the current
data-model.
So e.g. there would be a getName() method to get the data
representation of the name, and getFormatedName() which would first
call getName and then manipulate the name attribute to get a view
representation of it.
pro No more logic in the jsps, beans will not be "flooded" by
"duplicate attributes"
contra: Data model would still contain view-model getter methods.

Thanks for your advice,

Christine

In general, I think it's best to assume that the view model and the
business model are different. For instance, in the view model, you
almost always have to store the exact strings entered by the user,
certainly for semantic validation purposes, but you don't want this in
the business model. Even worse, I would be surprised if you didn't
have at least one case where there wasn't a 1-1 correspondence between
a view model entity and a business model entity.

In a complex application, it's best to construct the application in
layers, with a view model and view logic, then a business model and
business logic.

 

[Lew]

None of the above.

No scriptlet.

Use CSS for the formatting, not Java.

Use a view-logic layer, as david.karr suggested, for validation and the like.

Switch to JSF. It has a learning curve, but it's solved these questions.

 

[Christine Mayer]

Well, but the problem described is more specific - There is a String,
lets stay "This is my nice little String".
Now the user can search for a word, lets say "little".
In this case, I must call a function
public formatMyString(String myString, searchstring) {
.......
return formatedString
}

now currently, in the jsp, this function gets called like this
formatMyString("This is my nice little String", "little" )

which then will return on the view: "This is my nice <strong>little</
strong> String".

I don't think you could do something like that in JSF, could you??

 

[Lew]

Well, but the problem described is more specific - There is a String,
lets stay "This is my nice little String".
Now the user can search for a word, lets say "little".
In this case, I must call a function
public formatMyString(String myString, searchstring) {
.......
return formatedString
}

Consider spelling that variable "formattedString".

now currently, in the jsp, this function gets called like this
formatMyString("This is my nice little String", "little" )

which then will return on the view: "This is my nice <strong>little</
strong> String".

I don't think you could do something like that in JSF, could you??

Sure, and that way you'd avoid having that Java code appear in your JSP.

You could also do it with a custom tag.

It is common wisdom that avoiding Java scriptlet in a JSP is a best practice.
You asked about MVC; that implies moving the logic out of the JSP so that it
concerns itself only with the view.

What you do instead is submit the values to a controller servlet that forwards
the text to a validation or transformation method and adds the markup in
question. Use EL (expression language) to recover the altered value.

There are a number of idioms and hacks to get the search string and the search
term into parameters in the JSP that are processed on the back end.
Presumably you've solved that part of the problem.

The method you are using can be called on the back end, and that tends to make
better separation of concerns per your subject line.

 

[Christine Mayer]

Well, I also don't think we would switch to JSF so fast (political...)

> You could also do it with a custom tag.

No idea how to do a custom tag, I guess that must be very complicated.

>
> It is common wisdom that avoiding Java scriptlet in a JSP is a best
> practice. You asked about MVC; that implies moving the logic out of the
> JSP so that it concerns itself only with the view.

I know, I know! Thats why I posted my question in the first place!

>
> The method you are using can be called on the back end, and that tends
> to make better separation of concerns per your subject line.

Well, of course it can be called in the backend - but then I have to
save it in an additional attribute, or in an additional model,
and my question was if I should do it like that:

a) View Model and Data Model total separated, but mapping from one model
to the other necessary

Model MyDataModel {

private String myStringData;
[...]

public String getMyStringData(){
[...]
}

public void setMyStringData(String s) {
[...]
}
[...]

}

Model myViewModel {
[...]

private String myStringView;

public String getMyStringView(){
[...]
}

public void setMyStringView([...]
}
[...]
}
Controller MyController{
[...]
Model myDataModel = getMyDataModel();
Model myViewModel = new ViewModel();

for(object: myDataModel ){ // Assume my Model is somewhat more complex
[...]
String dataString = object.getMyStringData;
String viewString = convertMyString(dataString);
myViewModel.setMyStringView(viewString );
}
}

b) Only one model, no conversion necessary, but twice as much attributes
in one class, which are similar to each other.

Model MyModel {

private String myStringData;
private String myStringView;
[...]

public String getMyStringData(){
[...]
}

public void setMyStringData(String s) {
[...]
setMyStringView(s);
}


public String getMyStringView(){
[...]
}

public void setMyStringView(String s)
convertMyString(s);
[...]
}
[...]

}

}

or c) Only one model, only one attribute each, String gets converted
just in time (As the data will be re-retrieved with each re-request,
this is not really a problem)
Model MyModel {

private String myStringData;
[...]

public String getMyStringData(){
[...]
}

public void setMyStringData(String s) {
[...]
}


public String getMyStringView(){
return convertMyString(getMyStringData() );
[...]
}

[...]

}


Thanks in advance!