You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by M Rather <mr...@definedlogic.com> on 2007/12/17 16:32:38 UTC
design question regarding converters - who is responsible for building
hibernate converted object
Hello,
I have a design question regarding writing converters.
I have a detail screen of entity, say for example a customer, which has
a drop-down of another entity, for example an address.
A customer has an address, and both are model objects mapped in Hibernate.
In the detail screen of customer, I have a dropdown of addresses (why,
please ignore that, it is a simplified version of actual problem), and I
have written a SelectItems listing method which populates that address.
This field also has a converter, that takes the submitted address_id,
and builds an address object.
My question is:
Should it be the job of the converter to actually lookup an address
object from hibernate session and hand it over to customer (that way at
the time of saving customer, the customer does not have to worry about
proper linking to proper hibernate address object).
Or, should the converter just build a plain java address model object,
and customer should rehydrate it from hibernate session before saving
itself?
What is a better approach? Or is there any other practice that should be
followed?
Thanks
MRather
Re: How do I configure JSF application to use URLs without a suffix?
Posted by Andrew Robinson <an...@gmail.com>.
I think you can do it with facelets. Just create your files without an
extension.
You may also be able to do it with a custom view handler.
On Dec 17, 2007 2:26 PM, Zheng, Xiahong <Xi...@fmr.com> wrote:
>
>
> I know it must be possible. But I don't seem to be able to get it to work.
> It looks like if you use suffix based URL mapping in your web.xml like the
> following
>
> <servlet-mapping>
> <serlvet-name>Faces Servlet</servlet-name>
> <url-pattern>*.faces</url-pattern>
> </servlet-mapping>
>
> You URL will have to end up with .faces suffix like /myapp/welcome.faces. In
> this case, the suffix will be replaced by .jsp before rendering. I would
> like to use path based mapping such as
>
>
> <servlet-mapping>
> <serlvet-name>Faces Servlet</servlet-name>
> <url-pattern>/sample/*</url-pattern>
> </servlet-mapping>
>
> and be able to use URL like /myapp/sample/welcome. However, it does not
> work, because in this case, there is no attempt by the framework to add the
> default suffix .jsp to the viewId, as a result, I got a 404 resource not
> available error.
>
Re: How do I configure JSF application to use URLs without a suffix?
Posted by Samba <sa...@gmail.com>.
Search on Google for JSF URL Masking , you'll get a link which tells you how
to over ride the View handler to remove the suffix or prefix of a JSF Page
URL it's worth the effort. But right now I don't have the exact details.
I used it once in my earlier project (earlier company ,as well), but I do
not have it at my possession, right now to help you.
On Dec 18, 2007 7:17 AM, Stephen Friedrich <tr...@eekboom.com> wrote:
> I use tuckey to rewrite urls to the suffix form and back:
> http://tuckey.org/urlrewrite/
>
--
Regards...
Samba.
Re: How do I configure JSF application to use URLs without a suffix?
Posted by Stephen Friedrich <tr...@eekboom.com>.
I use tuckey to rewrite urls to the suffix form and back:
http://tuckey.org/urlrewrite/
Re: How do I configure JSF application to use URLs without a suffix?
Posted by Zigc Junk <zi...@gmail.com>.
I guess your welcome.jsp should be
/myapp/welcome.jsp
Then, you can get to it via
http://yourhost/sample/welcome.jsp
Bill
On Dec 17, 2007 3:26 PM, Zheng, Xiahong <Xi...@fmr.com> wrote:
> I know it must be possible. But I don't seem to be able to get it to
> work. It looks like if you use suffix based URL mapping in your web.xmllike the following
>
> <servlet-mapping>
> <serlvet-name>Faces Servlet</servlet-name>
> <url-pattern>*.faces</url-pattern>
> </servlet-mapping>
>
> You URL will have to end up with .faces suffix like /myapp/welcome.faces.
> In this case, the suffix will be replaced by .jsp before rendering. I would
> like to use path based mapping such as
>
> <servlet-mapping>
> <serlvet-name>Faces Servlet</servlet-name>
> <url-pattern>/sample/*</url-pattern>
> </servlet-mapping>
>
> and be able to use URL like /myapp/sample/welcome. However, it does not
> work, because in this case, there is no attempt by the framework to add the
> default suffix .jsp to the viewId, as a result, I got a 404 resource not
> available error.
>
How do I configure JSF application to use URLs without a suffix?
Posted by "Zheng, Xiahong" <Xi...@FMR.COM>.
I know it must be possible. But I don't seem to be able to get it to
work. It looks like if you use suffix based URL mapping in your web.xml
like the following
<servlet-mapping>
<serlvet-name>Faces Servlet</servlet-name>
<url-pattern>*.faces</url-pattern>
</servlet-mapping>
You URL will have to end up with .faces suffix like
/myapp/welcome.faces. In this case, the suffix will be replaced by .jsp
before rendering. I would like to use path based mapping such as
<servlet-mapping>
<serlvet-name>Faces Servlet</servlet-name>
<url-pattern>/sample/*</url-pattern>
</servlet-mapping>
and be able to use URL like /myapp/sample/welcome. However, it does not
work, because in this case, there is no attempt by the framework to add
the default suffix .jsp to the viewId, as a result, I got a 404 resource
not available error.
RE: design question regarding converters - who is responsible for building hibernate converted object
Posted by "Garner, Shawn" <Ga...@principal.com>.
Not in the converter.
-----Original Message-----
From: M Rather [mailto:mrather@definedlogic.com]
Sent: Monday, December 17, 2007 9:57 AM
To: MyFaces Discussion
Subject: Re: design question regarding converters - who is responsible
for building hibernate converted object
Well, access to persistence layer would go through service layer in both
cases..
The question is, which object should concern itself to building an
object which is persistence aware.
I was also leaning towards 'a converter should only do object to object
conversions. ' But I was looking towards some opinion of where the
lookup of address object from persistence before assigning to customer
should reside.. In the converter or the managed bean for customer.
MRather
Garner, Shawn wrote:
> It is my opinion that the UI should not concern itself with the
> persistence layer.
> The UI should delegate to the service layer which should delegate to
> persistence.
> IMO a converter should only do object to object conversions.
> What you are talking about I've seen done in the getter method of the
> bean that returns the list of select items or in the constructor.
> I've also seen it done in an action method of a handler backing bean.
> I've heard that shale has a hook to a view to initialize things prior
to
> rendering too.
>
> Shawn
>
>
> -----Original Message-----
> From: M Rather [mailto:mrather@definedlogic.com]
> Sent: Monday, December 17, 2007 9:33 AM
> To: MyFaces Discussion
> Subject: design question regarding converters - who is responsible for
> building hibernate converted object
>
> Hello,
>
> I have a design question regarding writing converters.
>
> I have a detail screen of entity, say for example a customer, which
has
> a drop-down of another entity, for example an address.
> A customer has an address, and both are model objects mapped in
> Hibernate.
>
> In the detail screen of customer, I have a dropdown of addresses (why,
> please ignore that, it is a simplified version of actual problem), and
I
>
> have written a SelectItems listing method which populates that
address.
> This field also has a converter, that takes the submitted address_id,
> and builds an address object.
>
> My question is:
> Should it be the job of the converter to actually lookup an address
> object from hibernate session and hand it over to customer (that way
at
> the time of saving customer, the customer does not have to worry
about
> proper linking to proper hibernate address object).
>
> Or, should the converter just build a plain java address model object,
> and customer should rehydrate it from hibernate session before saving
> itself?
>
> What is a better approach? Or is there any other practice that should
be
>
> followed?
>
> Thanks
> MRather
>
>
> -----Message Disclaimer-----
>
> This e-mail message is intended only for the use of the individual or
> entity to which it is addressed, and may contain information that is
> privileged, confidential and exempt from disclosure under applicable
law.
> If you are not the intended recipient, any dissemination, distribution
or
> copying of this communication is strictly prohibited. If you have
> received this communication in error, please notify us immediately by
> reply email to Connect@principal.com and delete or destroy all copies
of
> the original message and attachments thereto. Email sent to or from
the
> Principal Financial Group or any of its member companies may be
retained
> as required by law or regulation.
>
> Nothing in this message is intended to constitute an Electronic
signature
> for purposes of the Uniform Electronic Transactions Act (UETA) or the
> Electronic Signatures in Global and National Commerce Act ("E-Sign")
> unless a specific statement to the contrary is included in this
message.
>
> While this communication may be used to promote or market a
transaction
> or an idea that is discussed in the publication, it is intended to
provide
> general information about the subject matter covered and is provided
with
> the understanding that The Principal is not rendering legal,
accounting,
> or tax advice. It is not a marketed opinion and may not be used to
avoid
> penalties under the Internal Revenue Code. You should consult with
> appropriate counsel or other advisors on all matters pertaining to
legal,
> tax, or accounting obligations and requirements.
>
>
-----Message Disclaimer-----
This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by
reply email to Connect@principal.com and delete or destroy all copies of
the original message and attachments thereto. Email sent to or from the
Principal Financial Group or any of its member companies may be retained
as required by law or regulation.
Nothing in this message is intended to constitute an Electronic signature
for purposes of the Uniform Electronic Transactions Act (UETA) or the
Electronic Signatures in Global and National Commerce Act ("E-Sign")
unless a specific statement to the contrary is included in this message.
While this communication may be used to promote or market a transaction
or an idea that is discussed in the publication, it is intended to provide
general information about the subject matter covered and is provided with
the understanding that The Principal is not rendering legal, accounting,
or tax advice. It is not a marketed opinion and may not be used to avoid
penalties under the Internal Revenue Code. You should consult with
appropriate counsel or other advisors on all matters pertaining to legal,
tax, or accounting obligations and requirements.
Re: design question regarding converters - who is responsible for
building hibernate converted object
Posted by M Rather <mr...@definedlogic.com>.
Well, access to persistence layer would go through service layer in both
cases..
The question is, which object should concern itself to building an
object which is persistence aware.
I was also leaning towards 'a converter should only do object to object
conversions. ' But I was looking towards some opinion of where the
lookup of address object from persistence before assigning to customer
should reside.. In the converter or the managed bean for customer.
MRather
Garner, Shawn wrote:
> It is my opinion that the UI should not concern itself with the
> persistence layer.
> The UI should delegate to the service layer which should delegate to
> persistence.
> IMO a converter should only do object to object conversions.
> What you are talking about I've seen done in the getter method of the
> bean that returns the list of select items or in the constructor.
> I've also seen it done in an action method of a handler backing bean.
> I've heard that shale has a hook to a view to initialize things prior to
> rendering too.
>
> Shawn
>
>
> -----Original Message-----
> From: M Rather [mailto:mrather@definedlogic.com]
> Sent: Monday, December 17, 2007 9:33 AM
> To: MyFaces Discussion
> Subject: design question regarding converters - who is responsible for
> building hibernate converted object
>
> Hello,
>
> I have a design question regarding writing converters.
>
> I have a detail screen of entity, say for example a customer, which has
> a drop-down of another entity, for example an address.
> A customer has an address, and both are model objects mapped in
> Hibernate.
>
> In the detail screen of customer, I have a dropdown of addresses (why,
> please ignore that, it is a simplified version of actual problem), and I
>
> have written a SelectItems listing method which populates that address.
> This field also has a converter, that takes the submitted address_id,
> and builds an address object.
>
> My question is:
> Should it be the job of the converter to actually lookup an address
> object from hibernate session and hand it over to customer (that way at
> the time of saving customer, the customer does not have to worry about
> proper linking to proper hibernate address object).
>
> Or, should the converter just build a plain java address model object,
> and customer should rehydrate it from hibernate session before saving
> itself?
>
> What is a better approach? Or is there any other practice that should be
>
> followed?
>
> Thanks
> MRather
>
>
> -----Message Disclaimer-----
>
> This e-mail message is intended only for the use of the individual or
> entity to which it is addressed, and may contain information that is
> privileged, confidential and exempt from disclosure under applicable law.
> If you are not the intended recipient, any dissemination, distribution or
> copying of this communication is strictly prohibited. If you have
> received this communication in error, please notify us immediately by
> reply email to Connect@principal.com and delete or destroy all copies of
> the original message and attachments thereto. Email sent to or from the
> Principal Financial Group or any of its member companies may be retained
> as required by law or regulation.
>
> Nothing in this message is intended to constitute an Electronic signature
> for purposes of the Uniform Electronic Transactions Act (UETA) or the
> Electronic Signatures in Global and National Commerce Act ("E-Sign")
> unless a specific statement to the contrary is included in this message.
>
> While this communication may be used to promote or market a transaction
> or an idea that is discussed in the publication, it is intended to provide
> general information about the subject matter covered and is provided with
> the understanding that The Principal is not rendering legal, accounting,
> or tax advice. It is not a marketed opinion and may not be used to avoid
> penalties under the Internal Revenue Code. You should consult with
> appropriate counsel or other advisors on all matters pertaining to legal,
> tax, or accounting obligations and requirements.
>
>
RE: design question regarding converters - who is responsible for building hibernate converted object
Posted by "Garner, Shawn" <Ga...@principal.com>.
It is my opinion that the UI should not concern itself with the
persistence layer.
The UI should delegate to the service layer which should delegate to
persistence.
IMO a converter should only do object to object conversions.
What you are talking about I've seen done in the getter method of the
bean that returns the list of select items or in the constructor.
I've also seen it done in an action method of a handler backing bean.
I've heard that shale has a hook to a view to initialize things prior to
rendering too.
Shawn
-----Original Message-----
From: M Rather [mailto:mrather@definedlogic.com]
Sent: Monday, December 17, 2007 9:33 AM
To: MyFaces Discussion
Subject: design question regarding converters - who is responsible for
building hibernate converted object
Hello,
I have a design question regarding writing converters.
I have a detail screen of entity, say for example a customer, which has
a drop-down of another entity, for example an address.
A customer has an address, and both are model objects mapped in
Hibernate.
In the detail screen of customer, I have a dropdown of addresses (why,
please ignore that, it is a simplified version of actual problem), and I
have written a SelectItems listing method which populates that address.
This field also has a converter, that takes the submitted address_id,
and builds an address object.
My question is:
Should it be the job of the converter to actually lookup an address
object from hibernate session and hand it over to customer (that way at
the time of saving customer, the customer does not have to worry about
proper linking to proper hibernate address object).
Or, should the converter just build a plain java address model object,
and customer should rehydrate it from hibernate session before saving
itself?
What is a better approach? Or is there any other practice that should be
followed?
Thanks
MRather
-----Message Disclaimer-----
This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by
reply email to Connect@principal.com and delete or destroy all copies of
the original message and attachments thereto. Email sent to or from the
Principal Financial Group or any of its member companies may be retained
as required by law or regulation.
Nothing in this message is intended to constitute an Electronic signature
for purposes of the Uniform Electronic Transactions Act (UETA) or the
Electronic Signatures in Global and National Commerce Act ("E-Sign")
unless a specific statement to the contrary is included in this message.
While this communication may be used to promote or market a transaction
or an idea that is discussed in the publication, it is intended to provide
general information about the subject matter covered and is provided with
the understanding that The Principal is not rendering legal, accounting,
or tax advice. It is not a marketed opinion and may not be used to avoid
penalties under the Internal Revenue Code. You should consult with
appropriate counsel or other advisors on all matters pertaining to legal,
tax, or accounting obligations and requirements.