Tankred Smult

Hi.

Just wanted you to know I hacked my way around it.
I put the field in html as a hidden field:
<nested:hidden property="svar"/>
and then get the value in javascript by reading that property:
win1.document.write(document['skjemaForm']['linjer[<%=count%>].svar'].value);
It's what we in norway would call a "grisehack" (pighack), but it seems to work.

Still, if anyone know a more elegant solution, please let me know.

Well, not really. You see, I use the same formbean to extract the data, and in other cases I would like the \n to be included. It is just in the special case where I use it to generate a javascript string that I would like to replace it. So, if there were some kind of filer I could create and use, that would replace the \n's, that would be the best solution. Is that possible?

.tankred

Hi all!

I'm trying to pass a string from my jsp page to javascript, to make a javascript popup with a printerfriendly edition of my page. But I'm having a problem when the string contains a newline('\n'). It totally messes up my javascript:

win1.document.write('<nested:write property="answer"/></td>');

As I said, this works like a dream when there's no \n in "answer". I was hoping there was a way to strip out the \n's from the property. I've tried the filter option, hoping that it would strip out the \n, or even maybe replace them with <br/>s.

Do anyone know how to remove the \n's?

.tankred

Have you tried
<nested:text property="name"/>

instead of <html:text> ?

(Don't remember, but you might have to set the type in your iteration, something like:
<nested:iterate ... type="com.somepackage.IndexInfo">

Actually you don't have to guess on the actual number. Using the validator like I did in the validators.xml
[CODE]
<field property="answer" indexedListProperty="linjes" depends="required">
[CODE]
does actually validate the questions the way it should. The indexedListProperty is the property of the form-bean that will return a list, and "answer" is a property of the bean that exist in that list.

And this works just fine, if the user doesn't answer all the questions, I will get an validation error. And is a new question is added to the datebase, it too will be required with no change to the xml-document.

My problem is the errormessage that are shown to the user if he doesn't fill out the question. Then he will get an errormessage saying "You will have to answer the question".

But my bean that exist in the list (the one with the "answer" property also has a "question" property, that will return the actual question asked. So I would like struts to use the "question" property of that bean as arg0 (to the error message) instead of a statically and general parameter from my properties file.

So, it's not the validation itself that's the problem, it's the error-message to the user.

My question is how can I dynamically assign arg0 in the validator?

Here's the senario:

I have a list of questions which I get from a database, and I would like to put back answers. In my form-bean I have a property called "lines", which contain lines with questions and answers. I use like this (pseudocode):

<nested:iterate property="lines" type="Line" indexId="count"> <tr> <td><nested:write property="question"/></td> <td><nested:radio property="answer" value="yes"/></td> <td><nested:radio property="answer" value="no"/></td> </tr> </nested:iterate>

All the questions has to be answered, and I'm trying to do that with the validator framework (struts 1.1), like this:
<field property="answer" indexedListProperty="line" depends="required"> <arg0 key="label.question"/> </field>

the properties file:
label.question=Question

So, if a user doesn't answer a question, she will get an error saying "You must answer the question 'Question'" (that's what's in my properties file). However, I would like to use the "question" property of the bean which contains the actual question as arg0. So it would say
"You must answer the question 'Did you like the movie?'".

So maybe something like this instead (except it should work) :-)
<field property="answer" indexedListProperty="line" depends="required"> <arg0 property="question" indexedListProperty="line" resource="false"/> </field>

Can this be done? Does anyone know how?

I'm doing the Contractors assignment.
The problem is; we all want to throw IOExceptions, but we are not allowed to by the DBMain interface. Whrapping the IOException in one of the allowable checked exceptions is counterintuitive for client programmers. Unchecked exceptions are bad because it doesn't force clients to catch the exceptions.
Some solutions have been descibed in this thread, but I find them all a bit hacky. Then again, because of the DBMain interface there is no elegant solution to the problem.
However, the best solution I see is to throw a custom unchecked exception called UncheckedIOException from all the methods in Data where IOExceptions occur, using the actual IOException as the cause. Then document this in the javadoc like there's no tomorrow. And do not make Data public, instead make it only package visible!
Then make a new class called IOData, which have the exact same methods as data, but it will also declare IOExceptions. This class works as a adapter for the dataclass. It just calls the corresponding methods in the data class, catches the UncheckedIOExceptions, extracts the IOException whrapped inside and rethrows that IOException. The IOData class is the one available publicly (outside the package).
This way, at least you encapsulate the strange constrains gived by the DBMain interface within the suncertify.db package, hiding this awkwardness from clients(classes outside the db-package).

I don't think it is appropriate to just cut off the string at the end. The data class isn't capable of deciding the importance of the field, and whether or not it is ok to just cut off the end of the string, as it has no knowlegde of the data it is inserting.
In my assignment I've got a field called "Houry charge", which is 8 bytes. If a Contractor were charging say "$123456789.00", I don't think it would be ok if the database were to say he would charge only "$1234567".
Imagine the look on my face when I discover that the plumber I thought I got at the bargain price of $1234567/hour in fact demands $123456789.00.
This example is maybe not very realistic, but my point is, as the Data class has no knowlegde of the importance of the data, it should leave the decision up to it's client, not make one without even letting the client know.
So the way I see it, an exception is the only acceptable solution.

Hi.
I've decided to throw a
IllegalArgumentException in such cases, which is a runtime exception.
As long as you document what this method accepts as valid input in the javadoc, I do not think you should require the clients catch exceptions thrown if they violate this contract.
Even in suns api they don't. Imagine having to write this each time you create an integer:
try { Integer integer = new Interger("12") } catch(NumberFormatException e) { //handle exception }
Luckily NumberFormatException is a RuntimeException, so you don't have to.

Seems also like Jim Yingst posted a reply pointing out the same issues I adressed in my last posting when I was writing it.
Tanks for the help!

Seems I'm getting closer to a solution. There's one difference between my solution and the one in the book. In the book the class itself does not implement Remote directly, but instead a interface that implements Remote.
These examples will hopfully make this more clear. This does not work, as the fact that RemoteDataProxy implements DataProxy is considered a implementation detail by rmic when generating stubs:
interface DataProxy{ void doSomeThing() throws RemoteException; } class RemoteDataProxy extends UnicastRemoteObject implements DataProxy, Remote{ void doSomeThing() throws RemoteException{ //doSomething } }
Whereas this works (the difference is that I've put a interface in between DataProxy and RemoteDataProxy):
interface DataProxy{ void doSomeThing() throws RemoteException; } interface RemoteDataProxyInterface extends DataProxy, Remote { } class RemoteDataProxy extends UnicastRemoteObject implements RemoteDataProxyInterface{ void doSomeThing() throws RemoteException{ //doSomething } }
When rmic is called
rmic -v1.2 RemoteDataProxy
The stubs are actually generated for the RemoteDataProxyInterface, as this is the closest interface that implements Remote directly. The fact that RemoteDataProxyInterface extends DataProxy is not considered an implementation detail. Why not? Well, I'm not quite sure, but I guess it is because which interfaces an interface extend is not a detail. But which interfaces a class implements is. No, I don't get it either.
Anyway, seems I can get it to work by inserting this interface without having DataProxy extend Remote. This way my LocalDataProxy does not have to extend Remote indirectly, which means that I'm happy. At least for now. Which means I'll stop bugging you guys. At least for now...
...and they all lived happily ever after...

Thanks for answering!
Still, I don't quite get it.
It seems to me that what I've done is quite simular to what's been done in the book.
To review the code fragment I posted earlier:
interface DataProxy{ void doSomeThing() throws RemoteException; } class RemoteDataProxy extends UnicastRemoteObject implements DataProxy, Remote{ void doSomeThing() throws RemoteException{ //doSomething } }
The RemoteDataProxy is the made the remote object:
Naming.rebind( "DataProxy", remoteDataProxy );
On the client I connect to the remote object:
Remote remoteObject = Naming.lookup(url); return (DataProxy) remoteObject;
But when I try to cast the remoteObject into DataProxy, I get a cast-exception. I don't see how this is different from whats been done in the book.
If I understand the earlier post by Jim Yingst correctly; rmic, when generating the stubs, considers all non-Remote interfaces the remote object implements as implementation details that should be hidden from the client. Hence, the generated stubs do not implement any non-Remote interfaces.
However, looking at the code in the book it seems to me the generated stubs do implement non-Remote interfaces, as it is casted to one:
return (DBClient)Naming.lookup(svr);
What I would like to know is; in which cases the remote object can be casted to a non-Remote interface, and in which cases it cannot (obviously in mine, at least ). I would like to get it by teaspoon (don't know if this makes sense to you, it what we say in Norway when someone needs a thoroughly expaination).
Tanks for you patience!
Tankred
Not stupid, only slow!

I've now studied a book called "The Sun Certified Java Developer Exam with J2SE 1.4". In regards to RMI it seems like a remote object is indeed casted to a non-remote object:
return (DBClient)Naming.lookup(svr);
Where DBClient is a interface not extending Remote in any way. So it seems to me it is possible to cast a remote object (or actually it's stubs) into a interface not implementing Remote. Or have I missed something? If not, why doesn't the books code get a Cast-exception as I do?

Originally posted by Mike Southgate:

the data class and the interface it implements (DBAccess) do not extend remote. So what I did was to create a new interface that does extend remote with the same methods as the DBAccess interface. I then have to classes that implement this new interface. My server class and a localdata class. The server class extends unicastremoteobject but the localdata class doesn't.

I've done a simular thing regarding remote data acess vs. local access. My plan was just to have an interface called something like DataProxy, which have methods that throws RemoteException, and have my remote and local access classes extend that interface:

interface DataProxy { void doSomeThing() throws RemoteException; } class LocalDataProxy implements DataProxy { void doSomeThing() { //doSomething } } class RemoteDataProxy extends UnicastRemoteObject implements DataProxy, Remote { void doSomeThing() throws RemoteException { //doSomething } }
However, by not letting DataProxy extend Remote, I've got an ClassCastException when trying to cast RemoteDataProxy to DataProxy on the client (or, actually I'm trying to cast the RemoteDataProxy_Stubs to DataProxy). It seems it can only be casted to interfaces extending Remote for some (probably good) RMI reason that I don't see, as I'm not an RMI expert.

Anyway, I'm currently having DataProxy extend Remote, even though I would prefere it if I were able to cast the RemoteDataProxy_Stub to DataProxy even when DataProxy is not extending Remote. Because having DataProxy extend Remote indicates that the DataProxy is available remote (which is not the case for the LocalDataProxy).
Can anyone explain why DataProxy has to extend Remote, or has a link that explains this, or have a more elegant workaround for this problem?
Tankred

Well, what I have done is I've made the DataFacade the remote object, which means that in the code on the client there will never be a call to any lock-method. This is because the DataFacade lives on the server, and not in the client, so no lock-methods are available on the client.
My question is; is this a violation of the requirements?
I think one interpretation of the requirements is that the remote object has to have a lock/unlock method, and in that way "provide locking functionality as specified in the interface provided above" (which refers to the DBMain interface).
I'm unsure whether or not one could say that the DataFacade "provide locking functionality as specified in the interface provided above" by actually calling the lock/unlock methods in Data, but hide this from the client. (Which is the way I've done it). Any thoughts?