Bart Kummel

Hi Jan,

Thanks for your additions to the discussion, they're actually quite useful. I totally agree with your point about leveraging the benefits of CDI conversations.

Jan Groth wrote:The often-heard argument that model transformations are required for a "good" decoupling of layers and as such are essential for "good" architectures is best answered by asking if there are any concrete plans to exchange any layers in the near future. If the answer is somehow vague, than make an official note that you'll start implementing the model transformation the day the layer exchange is requested... :-)

This is exactly the type of discussion I meant . Glad to hear that I'm not the only one who gets involved in this type of discussion. Reminds me of the saying "premature optimization is the root of all evil"... ;)

Best regards,
Bart

Hi Richard,

Thanks again for your reply. Good tom mention the Transfer Object pattern in this regard. Although I knew the pattern, I did not realize that my approach in fact implements this pattern. Thanks!

Best regards,
BArt

Hi Richard,

Thanks for your reply. Let me rephrase my question a bit. Suppose we have a PersonServiceFacade, that has a getPersonById(...) method. Now when I call that method from my View/Controller layer, e.g. from a JSF/CDI managed bean, what I get is a detached Person entity. I'm fine with that; I just let the user manipulate the values within the object via a form and merge and persist the Person object as the user presses the "save" button.

However, sometimes people tell me it is not good to work with detachted entities directly. Those people either create DAO objects or manipulate the entities only via methods on the PersonServiceFacade. (E.g. setPersonName(Person person, String newName)) I don't see much harm in manipulating detached objects, as soon as you don't forget to merge them. On the other hand, creating extra DAO objects or similar strategies seems to introduce much boilerplate / repeated code.

What's your opinion on this? Can you give me some good arguments to settle this discussion once and for all?

Best regards,
Bart

Hi Richard!

Good to have another book on EJB 3.1 to choose from! It certainly looks interesting. I was wondering what you think of using Entities: should we use them only in the "Model" layer and use DAO's (or something similar) in the "View/Controller"-layer? Or do you think it is okay to pass them through the service facade and just use the same Entity objects throughout the entire application? Or do you think this choice should depend on the size of the application or maybe some other metric?

Best regards,
Bart Kummel

@Tim: publicized in this month's Linux Journal magazine? Tell me more! A review? An ad?

Hi everyone,

Congratulations to the winners! I hope you'll enhoy the book.

Best regards,
Bart Kummel

Okay, so you don't have a database and you use a text file for persistence. That all fine, but why do you call codepointAt()? Can't you just save the pasted text into the file "as is"? If you make sure that you use the right character encoding, this should be possible.

Hi,

I get the feeling you are making things too complicated. If you have a Unicode String, why would you want to convert it to code points and then let the browser convert it to readable characters again? I think you should just pass the Unicode String to the text area directly. Then if you get the encodings right, you have your Chinese characters in your text area and you don't need the intermediate flat file.

Best regards,
Bart

Sorry, I forgot the <f:selectItem> component doesn't have a rendered attribute. Then I guess there's no other option than creating your list in code and use a <f:selectItems>. That's a better solution anyway, as Tim mentioned correctly.

Best regards,
Bart

Hi,

Most JSF components have an escape attribute. If you set that to false, the "magic" characters will be displayed as expected.

Best regards,
Bart

So you have a "flat file" with Unicode text, right?
What do you want to display in the text area? Do you want to see Chinese characters in your text area? (本) Or do you want to see Unicode code points? (&#26412;)

Hi,

Do I understand it right that your bean.attrib1 property contains Chinese characters? And you want to display those in a text area? Why don't you set the Chinese characters as Unicode characters in your attrib1 property? That way you don't have to worry about the &...

Best regards,
Bart

Hi,

Perhaps you could try this:
<h:selectOneMenu id="EVENT_TYPE_CODE" value="#{bean.selectedEvent.eventTypeCode}"> <f:selectItem itemValue="#{bean.selectedEvent.eventTypeCode}" itemLabel="Appointment" rendered="#{bean.selectedEvent.eventTypeCode == 'APPT'}" /> <f:selectItem itemValue="MEET" itemLabel="Meeting" rendered="#{bean.selectedEvent.eventTypeCode == 'APPT'}" /> <f:selectItem itemValue="ANNV" itemLabel="Anniversary" rendered="#{bean.selectedEvent.eventTypeCode == 'APPT'}" /> </h:selectOneMenu>
Note that I removed the <c:choose> and moved your condition to the rendered attribute of each <f:selectItem>. Alse notice the } that moved to the end of the expression. I hope this helps...

Best regards,
Bart Kummel

Hi J,

I don't understand what exactly is your problem. However, I have a hint for you... Are you aware that there is also a <f:selectItems> component, that adds a list of items in one pass?

Best regards,
Bart

Hi Pushpa,

I think the problem is your partialTriggers attribute. I think it should start with a double colon, like this: partialTriggers="::subformPoll:poll". Hopt this helps...

Best regards,
Bart