Ok, I have a bean that needs to populate a table so I was trying to
work with ListDataModel and I can get it to work fine but where I'm
running into 'best practice' difficulties is after doing an update to
an item in the table, I want a fresh population of the ListDataModel
to be used on the result
Hi all,
I readed some similar thing about JSF/model/database issues.
I have a simple and effective "model/architecture" for JSF
practice. We have developed 4 projects in JSF/OJB. They are
all password protected, so I can't demo to you. The first 2 projects we
bumped lots hard things. JSF stil
mailto:[EMAIL PROTECTED]
Sent: Thursday, September 01, 2005 1:53 PM
To: MyFaces Discussion
Subject: more on architecture really confused on something (shocker:)
Ok, I have a bean that needs to populate a table so I was trying to
work with ListDataModel and I can get it to work fine but where I
On 9/1/05, Zhong Li <[EMAIL PROTECTED]> wrote:
> Back to the topic, the key thing is if you want use JSF, you have to keep
> database operation far from JSF beans.
I agree totally, but this doesn't help much with this question too much.
I'm using a ListDataModel just to display the stuff
I don't use Model too much, my view is, if you keep it in session
scope, you can use it, if not, use parameter instead of it. I bumped
some issue for data in request scope, sometime, it is different result
when you use action and actionLisener, also for popup window, you will
head on troubles. If J
the new list of data as an argument.
That's the approach we follow, anyway.
- Brendan
-Original Message-
From: Rick Reumann [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 01, 2005 1:53 PM
To: MyFaces Discussion
Subject: more on architecture really confused on something (shocker:)
Using a commandLink with the id/PK is not an option for navigation to the detail. First, it has to be passed as a hidden field over the HTML page - HTTP request. How are you going to get at that argument? (we solved this, but it is ugly). Second, you still go to the same "viewId" when clicking a co
d set of values,
those values should show up on the screen, which was his basic
question.
-
Brendan
-Original Message-From: ir. ing. Jan
Dockx [mailto:[EMAIL PROTECTED] Sent: Thursday, September 01, 2005
2:53 PMTo: MyFaces DiscussionSubject: Re: more on
architecture rea
On 9/1/05, CONNER, BRENDAN (SBCSI) <[EMAIL PROTECTED]> wrote:
> Are you trying to do everything in EmployeeListBean, or do you have an
> EmployeeListAction class to handle actions (e.g., looking up an
> employee's information, processing "Save") separate from the data? If
> you have a separate Emp
splay the list of employees
again.
Rick,
is that similar to what you're doing?
-
Brendan
-Original Message-From: Zhong Li
[mailto:[EMAIL PROTECTED] Sent: Thursday, September 01, 2005
3:06 PMTo: MyFaces DiscussionSubject: Re: more on
architecture really confused on
On 9/1/05, CONNER, BRENDAN (SBCSI) <[EMAIL PROTECTED]> wrote:
> Well, I don't personally see it as problematic, since, in your "typical"
> example, you say you need to remember to call request.setAttribute().
> If you just change this to calling getMyBean.setEmployees() instead,
> it's basically th
Can you guys explain the dataflow based on transaction point, when do
you need save in database? when just want refresh table?
PROTECTED]
Sent: Thursday, September 01, 2005 3:53 PM
To: MyFaces Discussion
Subject: Re: more on architecture really confused on something
(shocker:)
On 9/1/05, CONNER, BRENDAN (SBCSI) <[EMAIL PROTECTED]> wrote:
> Well, I don't personally see it as problematic, since, in your
"ty
Does that make sense?
- Brendan
-Original Message-
From: Rick Reumann [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 01, 2005 3:00 PM
To: MyFaces Discussion
Subject: Re: more on architecture really confused on something
(shocker:)
On 9/1/05, CONNER, BRENDAN (SBCSI) <[EMAIL PROTE
Let us go back master-detail issue, I think we just follow nature way to do it.
1. we define MasterBean, MasterBeanList and DetailBean.
2. we have masterPage.jsp show masterBeanList. have a link goto detailPage.jsp show DetailBean
3. some editable fields on detailPage.jsp and a button for save
Title: Message
We
don't put the bean in the session, but we *do* save it using
-
Brendan
-Original Message-From: Zhong Li
[mailto:[EMAIL PROTECTED] Sent: Thursday, September 01, 2005
4:42 PMTo: MyFaces DiscussionSubject: Re: more on
architecture really confus
put the bean in the session, but we *do* save it using
-
Brendan
-Original Message-From: Zhong Li
[mailto:[EMAIL PROTECTED]] Sent: Thursday, September 01, 2005
4:42 PMTo: MyFaces DiscussionSubject: Re: more on
architecture really confused on something (shocker:)Let
u
Keep things nature and easy guys.
Also something let us go back to Swing, the super model for JSF.
dataModels in Swing you can use it as long as you needs, but this isn't
case in JSF. If we want keep same thing in JSF, we have to have a way
to allow use to define a dataModel, give it a "datamodel scope", so
user can create one when
[mailto:[EMAIL PROTECTED] Sent: Thursday, September 01, 2005
4:50 PMTo: MyFaces DiscussionSubject: Re: more on
architecture really confused on something (shocker:)I
really don't like saveState, it make things confuse and complex. We can use it
to build a model/component, bu
: Thursday, September 01, 2005
4:56 PMTo: MyFaces DiscussionSubject: Re: more on
architecture really confused on something (shocker:)Also
something let us go back to Swing, the super model for JSF. dataModels in
Swing you can use it as long as you needs, but this isn't case in JSF
ns separate
from my action beans; there's no sense in saving my
methods.)
-
Brendan
-Original Message-From: Zhong Li
[mailto:[EMAIL PROTECTED]] Sent: Thursday, September 01, 2005
4:56 PMTo: MyFaces DiscussionSubject: Re: more on
architecture really confused on somethin
to:[EMAIL PROTECTED] Sent: Thursday, September 01, 2005
5:18 PMTo: MyFaces DiscussionSubject: Re: more on
architecture really confused on something (shocker:)I
always believe something like saveState is trick, trick is good and bad thing.
You better put it at back bean, not in JSF page. JS
CONNER, BRENDAN (SBCSI) wrote:
The bad thing with saveState is that it wont work if one use in its navigation rule.
I already tried to address this and it worked partly.
Wouldnt it be nice if (on redirect) myfaces will collect all
saveState-Beans and put them in session scope and after redire
Now Werner Punz has devised something like a server side saveState-
thingy in the JSF-COMP project on sourceforge.
Maybe you guys would be interested in checking that out?
regards,
Martin
On 9/2/05, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
> CONNER, BRENDAN (SBCSI) wrote:
> >
> The bad thin
saving anyway, because
otherwise JSF gets confused when we return from our pop-up windows.
- Brendan
-Original Message-
From: Mario Ivankovits [mailto:[EMAIL PROTECTED]
Sent: Friday, September 02, 2005 12:43 AM
To: MyFaces Discussion
Subject: Re: more on architecture really confused on so
te saving anyway, becauseotherwise JSF gets confused when we return from our pop-up windows.- Brendan-Original Message-From: Mario Ivankovits [mailto:
[EMAIL PROTECTED]]Sent: Friday, September 02, 2005 12:43 AMTo: MyFaces DiscussionSubject: Re: more on architecture really confused on somethi
CONNER, BRENDAN (SBCSI) wrote:
That's a good point about redirect; we don't do that. ;-)
Regarding the "browser back" button, I believe that that works OK if you
set "client-side" state saving, rather than "server-side." Have you
tried that? We have to do "client-side" state saving anyway, bec
and not only the beans, but also the locale, messages and everything
else that is relevant to JSF should be saved over a redirect...
we should really find someone to suggest this to the expert group.
well, why don't we do it ourselves? Let's ask Craig, Adam and Manfred
what they think of this - I
Martin Marinschek wrote:
well, why don't we do it ourselves? Let's ask Craig, Adam and Manfred
what they think of this - I am including their addresses here...
As I wrote in some post earlier, I already found a solution to save
beans over the redirect if they are marked with an interface.
It s
Well, but the scenario you are is the same as we have with a plain
forward - and we do handle this scenario well with the t:saveState tag
written exactly for making this work. If you need to reuse the request
parameter on page B you just put in a t:saveState component and you
are done.
Thing is th
Well, from the perspective of just what the JSF spec says,
the correct thing is happening - a redirect sets up a new request,
and everything you list (except Locale actually, which should
be preserved) gets blown away.
But from the perspective of making a users life non-painful,
I find the fact th
32 matches
Mail list logo
