Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / September 2007

Tip: Looking for answers? Try searching our database.

JSTL - Following MVC

Thread view: 
Christine Mayer - 12 Sep 2007 14:02 GMT
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 - 12 Sep 2007 18:00 GMT
> 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
[quoted text clipped - 29 lines]
>
> 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 - 13 Sep 2007 02:12 GMT
>> 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
[quoted text clipped - 25 lines]
>> "duplicate attributes"
>> contra: Data model would still contain view-model getter methods.

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.

Signature

Lew

Christine Mayer - 13 Sep 2007 20:55 GMT
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 - 14 Sep 2007 03:06 GMT
> Well, but the problem described is more specific - There is a String,
> lets stay "This is my nice little String".
[quoted text clipped - 4 lines]
>     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" )
[quoted text clipped - 3 lines]
>
> 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.

Signature

Lew

Christine Mayer - 14 Sep 2007 07:13 GMT
Lew schrieb:
>> I don't think you could do something like that in JSF, could you??

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!


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.