Bert Bertens

Hi,

I was wondering what's the best way to do the following.

client logs in on website,
client selects a "Project"
client uploads an "Image" for the selected "Project".

I have a Project-class which contains a Set of Image-instances.

this is the code when the user presses the upload-button, from the ImageBean-class:
Project p = projectService.getProjectById(projectId); p.addImage(uploadedImage); imageService.create(uploadedImage); projectService.update(p);

Is this a good way to do it? Or should the create-method of the imageService-class do the p.addImage and projectService.update stuff?
Or should there be a projectService.addImageForProject(Image image) method?

Kind regards

Tim Holloway wrote:The decorator class is usually something you write, since the point of it is to add features that you need that the underlying object doesn't have. In the case of datatables, you can do things like create a list of decorators and fill it by enumerating the underlying object collection, constructing a decorator object for each underlying object, and inserting the decorator into the decorator list, which is then wrapped by a ListDataModel.

Which is a lot less fun than simply wrapping the underlying collection, since you can do that in a single line of code. But sometimes the extra work is worth the price.

I think I'm gonna go the easy way for now, however, another problem that comes to mind is the IoC, how can I set the LoginBean-property on RouteDecorato-class.
In the faces-config.xml I can't create a bean for the Router-class, because what scope would I define. After all, I instantiate the Route-class in the RouteController-class, several times, before returning the total Collection to the JSF.
For now I use this:
public boolean isCurrentDriver() { FacesContext context = FacesContextHelper.getCurrentFacesContext(); LoginBean loginBean = (LoginBean) context.getExternalContext().getSessionMap().get("loginBean"); return (loginBean.getEmail().equals(this.getDriver().getEmail())); }

Tim Holloway wrote:
Don't feel bad about the design patterns. Actually codifying and naming these critters was a relatively recent event, although some of these techniques I've been using for years. The iterator pattern got to be blatantly obvious when I moved to C++. Seemed like almost everything I did for a while had an iterator in it.

I don't, I enjoyed learning about them but have not yet been able to effectively use them in my design. Maybe I'll implement it here, but first I'm just gonna try and make the deadline for now.

Tim Holloway wrote:"Uncatholic" is a perfectly good word, but probably not the best one to use here, since "catholic" is more in the lines of "universal". "un-kosher", if you will.

A Decorator is one of the Gang of Four (GoF) Design Patterns, and it's basically a proxy or wrapper for an object that "decorates" that object with additional properties. In this particular case, adding the "isDriver()" read-only property method to the setter/getter methods that it repeats from the object being decorated. From the sound of it, however, you have enough control over the base object that in your case you can just add isDriver to the original class and not need a separate decorator.

However, if you want to talk "un-kosher", if not dowright haram (going muslim just to complete the roster), Using FacesContext.getSession.getBean is not the way to go. If you need to access one JSF managed bean from another managed bean, use property injection (Inversion of Control).

As a general rule, the less JSF-specific code that's in a bean, the better.

Ah, Ive only been properly introduced to design patterns since half a year, so I didn't immediatly see this implemented (since Hibernate returns Route-classes, and not RouteDecorator-classes). I also could be talking complete rubbish here and reread the book I have on design patterns, but for now I'll just go with the IoC-way.

Thanks for the multicultural help!

Tim Holloway wrote:
Urk. I'll stack my technical expertise against anyone's. But don't ever depend on me to have a proper sense of time.

Alright. I wish the website I'm making didn't have a proper sense of time, unfortunately, it has to be done by Friday. This is of course a minor thing not working, but I would like to see it finished.

I still don't understand how to implement your decorator-solution, could you please further explain it?

If this isn't going to work I'm gonna add a boolean-attribute 'isDriver' to the Route-class and work the getter out something like this:
PSEUDO LoginBean loginBean = FacesContext.getSession.getBean("loginBean"); return (loginBean.getEmail().equals(this.driver.getEmail());
But I wouldn't like that solution since it's uncatholic. (is that an expression?)

Tim Holloway wrote:
I think you're making the common, but incorrect assumption that a datatable has to be bound to the domain data. A JSF datatable is a Model object, and its primary purpose isn't domain data, it's to server as the Model part of MVC. And, just like the Model objects in, say, Swing, the JSF model objects are go-betweens with personalities of their own, not just placeholders.

If I understand correctly, I must bound the datatable to a Collection. In my case, a Collection of Route-objects. I still don't understand how I can 'decorate' this class so I can choose the appropriate image. Is 'decorating' the rendering of the h:datatable component you are referring to?

Tim Holloway wrote:
BTW, you don't "call" a routeBean.isDriver on your JSF view. You reference the routeBean's driver property. That's an important distinction to make since A), "routeBean.isDriver" won't work as a value attribute, and B), value objects are lvalues. Meaning that not only is "isDriver invoked, but setDriver, as well. All the calling (or invoking, in OO terminology) is done by the framework. The JSF tags are specifications, not code.

Good point.

Tim Holloway wrote:
Yup. Not everyone who's "Over the Hill" is "Behind the Times" :)

I meant that I don't think JSF existed back then, since Servlets originate from 1997 :) But I get the point.

Tim Holloway wrote:
What you are doing wrong is mixing JSTL with JSF. I won't say you should never do that, but I haven't found a good reason to use JSTL on a JSF page ever and I've been working with JSF since about 1985.

I thought that this was the best way to do the condition, since I'm working with 2 parameters.

Tim Holloway wrote:
There's nothing a <c:out> can do that an <h:outputText> can't do.
To display an element conditionally, use the JSF tag's "rendered" attribute. You don't need to wrap the tag with conditional logic. You can select between 2 alternatives images using a "bean.x" property by using the 'rendered="#{bean.x}"' attribute on the first image and 'rendered="#{! bean.x}"' on the second. If you have more than 2 alternatives, I'll leave that as an exercise for you.

The problem is that this is in a datatable, a List<Route> gets rendered (var="route"). I could add a property in the Route-class and return a boolean if the driver's email is the email of the user logged in, but that would be a bad OO-design I guess, so I can't do rendered="#{route.isDriver}".
The backing bean is appropriate I think for checking if the user is the driver of the #{route}, but I can't call the #{routeBean.isDriver}-method and specify a parameter, and then return the appropriate image, or can I?

Also, 1985 JSF? Isn't that a bit early?

Can you deploy the WAR file in Tomcat? Does Tomcat give an error?

At what context path is it being deployed (http://localhost:8080/...)

Hi,

I need to display "driver.png"-image when the route.driver.email is the same email as the user logged in, otherwise the "passenger.png"-image.

I figured following code would be suitable:

<h:dataTable value="#{routeBean.routesForUser}" var="route" styleClass="routeTable"> <h:column headerClass="routeAccessCol"> <f:facet name="header"> <h:outputText value=" "/> </f:facet> <h:outputText value="driverEmail1: #{route.driver.email}"/><br/> <c:set var="loginEmail" value="#{loginBean.email}"/> <c:set var="driverEmail" value="#{route.driver.email}"/> <c:out value="Login: ${loginEmail},Driver: ${driverEmail}"/> <br/> <c:choose> <c:when test="${driverEmail == loginEmail}" ><h:graphicImage value="images/driver.png"/></c:when> <c:otherwise><h:graphicImage value="images/passenger.png"/> </c:otherwise> </c:choose> </h:column>

However, I can't pass the variable #{route.driver.email} to JSTL "driverEmail", because this is the output:

driverEmail1: testEmail
Login: testEmail, Driver:
<image passenger.png>

so "driverEmail" is null.

I wonder if anyone has a better solution for this problem, or can tell me what I am doing wrong?

Regards

1. shutdown tomcat manually
2. go to webapps folder and remove .war and folder of your project
3. startup tomcat, and try deploying the war again

works with me!

thanks! I totally looked over that link, think I'm gonna go with the interceptor way.

This thread is about the JSF caching problem: http://seamframework.org/Documentation/WhyDoesJSFCallMyGetterHundredsOfTimes

I have a <h:dataTable> which calls bean.getList, which creates a query to the database and returns some objects. I obviously don't want this method to be accessed so many times.

I wonder if anyone has a good solution to solve this problem?

Ulf Dittmer wrote:Which JRE version and which JSF version are you using? JSF 1.2 requires at least Java 5 (since it's part of JEE 5), while JSF 2.0 requires Java 6 (since it's part of JEE 6).

Is there a class file version number given in the error message? Should be a number around 50.

No I meant with my post that my problem was already solved. After googling my error I found that there's a JDK difference between Tomcat and Maven, so I just googled how to change Tomcat's JDK version and found this thread. But I had been searching long before I realised that the JDK difference was the problem (I had two JDK's on my pc and the system environment variable pointed to the outdated JDK, which Tomcat uses) so I thought I'd post the error message here so Googlers might end up here.

benjamin muktesh wrote:Go to tomcat/bin and modify the JAVA_HOME parmater in catalina.sh (for linux/unix) or catalina.bat (for windows)

Ive been searching for days for this solution,
I've had this error and now it's solved:
javax.servlet.ServletException: Bad version number in .class file
for my Java Server Faces JSF beans which all gave errors.