that file to set/use the properties.
-Original Message-
From: Jim May [mailto:jim.webg...@gmail.com]
Sent: Monday, October 24, 2011 4:47 PM
To: MyFaces Discussion
Subject: Best practice for storing application variables
I know this question is not directly associated with MyFaces, but
be
set programmatically as of servlet API 3.0.
On Mon, Oct 24, 2011 at 10:46 PM, Jim May wrote:
> I know this question is not directly associated with MyFaces, but more a
> general web application question.
>
> What is the best practice for storing application variables tha
We use a properties file, formatted by ant build file and deployed via a
rpm spec file depending on the environment its in.
-Original Message-
From: Jim May [mailto:jim.webg...@gmail.com]
Sent: 24 October 2011 10:47 PM
To: MyFaces Discussion
Subject: Best practice for storing application
, at 1:46 PM, Jim May wrote:
> I know this question is not directly associated with MyFaces, but more a
> general web application question.
>
> What is the best practice for storing application variables that need to be
> changed once deployed to an environment? I want to use these
I know this question is not directly associated with MyFaces, but more a
general web application question.
What is the best practice for storing application variables that need to be
changed once deployed to an environment? I want to use these variables in my
application scoped bean in the JSF
on-case configuration you are now able to pass the key
> from one view to the other.
> On the receiving side you have to use the parameterMap to fetch the key
> and reload the entity then.
>
> It depends on your application if it is feasable to render the key in the
> url. It
it is feasable to render the key in the url.
It makes them bookmarkable, but also vulnerable.
In this area it is hard to tell what is "best practice".
I normally use 1 or 2 and sometimes 2a :-)
Ciao,
Mario
-Ursprüngliche Nachricht-
Von: jid1 [mailto:ideligian...
(as it's not supposed to be best practice)
Also I could use:
But:
a. The first component will access the second in the JSF domain
b. I would like to do it from the backing bean so I can call
Conversation.getCurrentInstance().invalidate();
Can you please tell me the 'best practice
|| isCsvFileUpdated()) {
loadDataList(); // Reload to get most recent data.
}
return this.dataList;
}
Is this approach fine? Do you see any issue with this appraoch?
TIA...
--
View this message in context:
http://www.nabble.com/Datatable-usage-best-practice-question
trings stored somewhere in the
presentation layer, for example in a message.properties file, which I can
use in the JSP file. But how to do that efficiently and what"s the best
practice for doing so? I frequently have this problem, not only with String
types, but also with Java 1.5 Enum types….
> >
> > This would produce output like this on my webpage:
> >
> > ‘CatA’ or ‘CatB’ or ‘CatC’
> >
> > The problem is that I don’t want to display these raw values of the
> > JavaBean, instead I want to display specific strings stored somewhere
> >
tions).
Disadvantages:
Increased processing to create/recreate request-scoped beans.
Increased processing, bandwidth and client memory required to use
t:saveState.
This stuff may well be obvious to most people viewing this forum, so if
you
think its obvious/rubbish/useful please let me know (and
s/rubbish/useful please let me know (and preferably why :-)
all comments/feedback welcome...
Thanks
Nick
--
View this message in context:
http://www.nabble.com/Best-Practice-Suggestions-tf2644584.html#a7382547
Sent from the MyFaces - Users mailing list archive at Nabble.com.
26. Oktober 2006 17:22
An: MyFaces Discussion
Betreff: Re: AW: Best Practice - Converting raw property values of Beans
It is "cheating" because I put UI specific code in my enumeration (the
bundle key). I didn't feel that great about it, but it worked well
enough for me to use it.
On 1
ht-
> Von: Andrew Robinson [mailto:[EMAIL PROTECTED]
> Gesendet: Mittwoch, 25. Oktober 2006 22:30
> An: MyFaces Discussion
> Betreff: Re: Best Practice - Converting raw property values of Beans
>
> I "cheated" and made an interface for enum types:
(Why is this cheating
Bieringer Dominik wrote:
Okay, Where can i find information about the technique you are talking
about?
As luck would have it, I wrote a blog entry about that technique (EL
functions) last week, but hadn't got round to posting it up yet. Your
question has motivated me to post it, so it's here:
:[EMAIL PROTECTED]
Gesendet: Donnerstag, 26. Oktober 2006 00:23
An: MyFaces Discussion
Betreff: Re: AW: Best Practice - Converting raw property values of Beans
Bieringer Dominik wrote:
> Hey cool... thx very much... I didn't knew about the possibility to access
> the message from the
age.
-Ursprüngliche Nachricht-
Von: Andrew Robinson [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 25. Oktober 2006 22:30
An: MyFaces Discussion
Betreff: Re: Best Practice - Converting raw property values of Beans
I "cheated" and made an interface for enum types:
(Why is
Thx. Very much... I will read the docs tomorrow I think. It sounds really
promising ;)
-Ursprüngliche Nachricht-
Von: Gert Vanthienen [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 25. Oktober 2006 22:29
An: MyFaces Discussion
Betreff: Re: Best Practice - Converting raw property values of
treff: Re: Best Practice - Converting raw property values of Beans
I "cheated" and made an interface for enum types:
public interfaces EnumDescribed
{
public String getBundleKey();
}
public enum TestEnum
implements EnumDescribed
{
A("test.a"),
B("test.b"
#x27;CatB' or 'CatC'
The problem is that I don't want to display these raw values of the
JavaBean, instead I want to display specific strings stored somewhere in the
presentation layer, for example in a message.properties file, which I can
use in the JSP file. But how to do that ef
values of the
JavaBean, instead I want to display specific strings stored somewhere in the
presentation layer, for example in a message.properties file, which I can
use in the JSP file. But how to do that efficiently and what"s the best
practice for doing so? I frequently have this problem, n
er, for example in a message.properties file,
which I can use in the JSP file. But how to do that efficiently and
what”s the best practice for doing so? I frequently have this problem,
not only with String types, but also with Java 1.5 Enum types….
At the moment I am solving the problem the followi
that I don’t want to display
these raw values of the JavaBean, instead I want to display specific strings
stored somewhere in the presentation layer, for example in a message.properties
file, which I can use in the JSP file. But how to do that efficiently and what”s
the best practice for doing so? I
I hit refresh, I'd see the same
behavior.
I know I could just
judiciously log-out before a restart and circumvent the issue, however,
end-users won't be so polite, they will just let their JSF stay open across
server restarts and expired sessions, in a production
environment.
S
ion is gone. It only knows> what selected in the current page. I have two questions now:>> 1. What is the best practice in doing such web pages. Should it remember
> stuff selected from the first page?> 2. How to do it in using with ?>> In my opinion, it would be nice if we can
Hi.
I have one question for you. For the solution posted on wiki page of
large data set , when you select several rows on the first
page, then go to the next page, the selection is gone. It only knows
what selected in the current page. I have two questions now:
1. What is the best practice
Hi,
I have one question for you. For the solution posted on wiki page of large data set , when you select several rows on the first page, then go to the next page, the selection is gone. It only knows what selected in the current page. I have two questions now:
1. What is the best practice in
é : mercredi 31 août 2005 21:55
> À : MyFaces Discussion
> Objet : RE: Thanks and a best practice question in regard to set up of
> backing bean Actions
>
>
> You'll also want an EmployeeBean as a managed bean, which can be defined as
> having type EmployeeVO.
>
&g
used to believe the answer, but since this discussion
nothing is really clear anymore.
Thx
Clément
-Message d'origine-
De : CONNER, BRENDAN (SBCSI) [mailto:[EMAIL PROTECTED]
Envoyé : mercredi 31 août 2005 21:55
À : MyFaces Discussion
Objet : RE: Thanks and a best practice questi
t: Wednesday, August 31, 2005 12:48 PM
To: MyFaces Discussion
Subject: Thanks and a best practice question in regard to set up of
backing bean Actions
Thanks everyone for your help with the crud demo app I've been working
with. (Special thanks to Brendan for his fine "Car" example co
Thanks everyone for your help with the crud demo app I've been working
with. (Special thanks to Brendan for his fine "Car" example code that
he posted in another thread).
I want to start out on the right foot doing things in a 'correct' way
before I get into some bad practices.
Currently, I have
Hi folks,
I searched around for a few minutes now, regarding "redirection after
successfull form submit" for example, and I found a few ways to do it. What I
am wondering was, which way I should use in which situation and which ways is
the "best practice" way. Perhaps thi
Werner Punz wrote:
Some, but none of them is an easy plug and play thing.
The scopes are one big hole in the current faces specs,
as Martin has pointed out you can do it with x:saveState
but then you need serialization.
Another thing would be to remove the bean from the session as soon as
you hi
Some, but none of them is an easy plug and play thing.
The scopes are one big hole in the current faces specs,
as Martin has pointed out you can do it with x:saveState
but then you need serialization.
Another thing would be to remove the bean from the session as soon as
you hit the point where yo
Oh thanks Martin, this sounds interesting! I'll take a look at the
saveState-Tags tomorrow!
Am Sonntag, 5. Juni 2005 21:40 schrieb Martin Marinschek:
> what about the x:saveState tags in MyFaces?
>
> I use these tags extensively to store only those beans I need exactly
> as long as they are neede
what about the x:saveState tags in MyFaces?
I use these tags extensively to store only those beans I need exactly
as long as they are needed...
But also the request approach will work: not only the changed values
are posted back to the server, but all values, so you get an
initialized bean anyway
Hi guys,
I have the following problem: lets suppose I have a managed-bean which should
be filled with content by the database if the user requests some certain
informations and then the content of this bean should be rendered in the
JSF-page. Then, after it is rendered (after the first request)
Isn't there a commons validator that does something like this? If so,
shale has adapted all of those validators to make them available in
JSF. I haven't tried it but I believe you could use that portion of
shale without configuring the rest of the shale stuff (in other words,
it works independent
> Anyone who knows something different?
I would put a custom validator on the company name which checks the
other fields if the company name was null.
--
Norbert Csík
No, not that I would know of some better way to handle that.
JSF generally just supports validators with a relationship to one
field, for everything else you need to work yourself.
Anyone who knows something different?
regards,
Martin
On 5/25/05, Jan Bols <[EMAIL PROTECTED]> wrote:
> I have a
I have a form containing (among others) a field to fill in a company name
and fields to fill in the address of the company (street, nr, bus, zip,
city, country). I want to give an error message when the user fills one of
the address fileds but not the company name.
The way I solved the prob
nal Message-
> From: Bjørn T Johansen [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 24, 2005 7:04 PM
> To: MyFaces Discussion
> Subject: Re: Best practice?
>
> But how to you fill the data in the MB from DAO?
>
> Jesse Alexander (KBSA 21) wrote:
>
>>Well we call
l the UserDetails...
in the JSP the details then can be accessed "normally":
#{myManagedBean.userDetails.lastName}
and so on...
-Original Message-
From: Bjørn T Johansen [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 24, 2005 7:04 PM
To: MyFaces Discussion
Subject: Re: Best
hansen [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 24, 2005 6:18 PM
> To: MyFaces Discussion
> Subject: Re: Best practice?
>
> Yes, that's what I was thinking about... But I am not sure if I should pass
> the managed
> bean just to my business layer and use VO from BO
Well we call the the Business-Layer from the managed beans, therefor we have no
need to
pass the MB to the backend...
Alexander
-Original Message-
From: Bjørn T Johansen [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 24, 2005 6:18 PM
To: MyFaces Discussion
Subject: Re: Best practice
2005 12:17 PM
> To: MyFaces Discussion
> Subject: Re: Best practice?
>
> I have looked at the website before, but I haven't tried it yet... But
> isn't Shale still
> at it's early development state?
>
> Matthias Wessendorf wrote:
> > Bjørn,
> >
>
t;best practise"? I do not know, but it works (so
>> far) for our project on which 4 people are working full time plus one
>> JSF component developer.
>>
>> hth
>> Alexander
>>
>> -Original Message-
>> From: Bjørn T Johansen [mailto:[EMAIL P
are working full time plus one JSF component
> developer.
>
> hth
> Alexander
>
> -Original Message-
> From: Bjørn T Johansen [mailto:[EMAIL PROTECTED]
> Sent: Monday, May 23, 2005 8:52 AM
> To: MyFaces Discussion
> Subject: Best practice?
>
> I was wondering
I have looked at the website before, but I haven't tried it yet... But isn't
Shale still
at it's early development state?
Matthias Wessendorf wrote:
> Bjørn,
>
> it is now worth to look at Shale.
>
> Shale provides an interface that each backing bean *could* implement
> it provides a init() met
e"? I do not know, but it works (so far) for our
project on which 4 people are working full time plus one JSF component developer.
hth
Alexander
-Original Message-
From: Bjørn T Johansen [mailto:[EMAIL PROTECTED]
Sent: Monday, May 23, 2005 8:52 AM
To: MyFaces Discussion
Subject
Bjørn,it is now worth to look at Shale.Shale provides an interface that each backing bean *could* implementit provides a init() method for initializing stuff like you want.(see:
http://people.apache.org/~craigmcc/shale-core-javadocs/org/apache/shale/ViewController.html)There
is use case app, that
component
developer.
hth
Alexander
-Original Message-
From: Bjørn T Johansen [mailto:[EMAIL PROTECTED]
Sent: Monday, May 23, 2005 8:52 AM
To: MyFaces Discussion
Subject: Best practice?
I was wondering what's the best way of handling the following:
- A managed bean need to be
I was wondering what's the best way of handling the following:
- A managed bean need to be "filled" with data from a database using DAO
methods; is
it best just to pass the managed bean as parameter og should one use another VO
bean
and populate the managed bean from the VO bean?
- when moving
> On 5/6/05, Sylvain Vieujot <[EMAIL PROTECTED]>wrote: > > I don't know if this really helps in your case, but have a look at the > > x:aliasBean tag. > > I use it to have generic subforms, and it works pretty well. > > Thanks. I'll look for an example on Monday. > > > > On 5/6/05, [EMAIL PROTECTE
On 5/6/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote:
> I don't know if this really helps in your case, but have a look at the
> x:aliasBean tag.
> I use it to have generic subforms, and it works pretty well.
Thanks. I'll look for an example on Monday.
On 5/6/05, [EMAIL PROTECTED] <[EMAIL P
> Well, it appears that simple reuse like this isn't possible under JSF.
You might check out the Clay component under Struts Shale:
http://cvs.apache.org/builds/struts/nightly/struts-shale/clay-plugin
This component will allow you to define a sub-tree within a jsp page where the
component meta
I don't know if this really helps in your case, but have a look at the x:aliasBean tag.
I use it to have generic subforms, and it works pretty well.
On Fri, 2005-05-06 at 16:28 -0400, Mike Kienenberger wrote:
Well, it appears that simple reuse like this isn't possible under JSF.
What would
Well, it appears that simple reuse like this isn't possible under JSF.
What would have been a five-minute task under WebObjects, and maybe a
five-hour task with Struts/Velocity became a 30-hour ordeal of
creating a custom composite component
(HtmlDataTable/UIColumn/UIColumns/UICommand) in JSF, and
I've got a "RowAndColumnRelationshipsPage.jspx" with an associated
RowAndColumnRelationshipsPage backing bean.
I have a large number of row-and-column-based "data source" classes
that implement a RowAndColumnRelationshipData interface which will
provide the actual data displayed on the page.
Howe
14:00:32 +0100, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Hi
>
> What is the best practice for the following scenario :
>
> I have a page that can display different events. From the menu
> (JSCookMenu) you should be able select a specicif event, and be sent to
> th
Hi
What is the best practice for the following scenario :
I have a page that can display different events. From the menu
(JSCookMenu) you should be able select a specicif event, and be sent to
this page which in turn would display the data for that event. In good
ol' Struts you would do
where
saving to a database might be more appropriate.
sean
On Fri, 11 Feb 2005 05:37:14 -0800 (PST), mfaine <[EMAIL PROTECTED]> wrote:
> In a web application I am writing a user edits an object in a multi-step
> process. What would be the best practice of the two:
>
> A. Save a
In a web application I am writing a user edits an object in a multi-step
process. What would be the best practice of the two:
A. Save and Restore the state to/from the database at each step.
B. Save and Restore the state to/from the session and only save to the
database at the end of the
64 matches
Mail list logo
