rife-users Google Group

Question : L10N language switch facility

2009-12-10T16:12:19Z

Hi all,

I am trying to add l10n language switch facility to my site and I have a
question

Is it possible to use url as input for what language to use? For example:
1. If I use url "/nl/root" or "/wortel, then the site should display index
page with nl language
2. If I use url "/root" then by default the site should display en language

Re: [rife-users] Re: MetaData Constraint / primary key("A","B")

2009-11-22T19:41:01Z

Hi Soufiane,

This isn't supported by RIFE, sorry. The MetaData constraints work well for certain use-case but there are a lot of other that simply aren't thought out yet or don't make sense.

Best regards,

Geert

--
Geert Bevin
Terracotta - [link]
Uwyn "Use what you need" - [link]

Re: MetaData Constraint / primary key("A","B")

2009-11-22T14:29:02Z

Hi,

I didnt found yet any solutions :(

Best Regards,

Soufiane.

MetaData Constraint / primary key("A","B")

2009-11-20T15:00:09Z

Hi Geert,

I have a little question about custom rife bean.

With this example :
In Oracle database
CREATE TABLE "AUTHFUNCTIONLINK"
( "ROLEID" NUMBER(19,0) NOT NULL ENABLE,
"FUNCTIONID" NUMBER(10,0) NOT NULL ENABLE,
CONSTRAINT "AUTHFUNCTIONLINK_PK" PRIMARY KEY ("ROLEID",
"FUNCTIONID")

Re: [rife-users] Re: LOGOUT / back & page reloading.

2009-11-18T21:18:07Z

Hi Soufiane,

A typical approach is to redirect after post. You could extend from a generic element that always redirects after authentication using the redirect() method. Another option is to declare a flowlink as being redirect and trigger an exit that uses that link after authentication. Another option is to actually work with continuations and as you suggest erase the entire continuation tree of the active user with "ContinuationContext.getActive Context().removeContextTree(); ". You could also add an element inheritance layer that sets a global var or a cookie each time a GET happens and only allows a POST when the value is set. A final option I can think of is to simply always prevent continuations to be cloned with setCloneContinuations(false) in an element, the back button will then not have a valid context to work with.

Re: LOGOUT / back & page reloading.

2009-11-18T19:38:49Z

Hi Joshua,

Understood.

I'll try to find a solution without write my own auth system.
After that, i will check if i can simply extends RIFE's system.

Thanks !
Best regards,
Soufiane

Re: [rife-users] LOGOUT / back & page reloading.

2009-11-18T16:43:17Z

Hi Soufiane,

This is a standard issue related to the browser, rather than with RIFE.
The submitted form values are associated with the page being viewed, so
a refresh will usually result in the browser prompting the user about
whether to re-submit the form values.

As far as I know, RIFE's built-in authentication system does not support

LOGOUT / back & page reloading.

2009-11-18T11:07:10Z

Hello Geert !

I'm concerned about the example [link]
After a logout, when an user go back with the navigator's back button
and refresh the page, he can resend a revalidation POST request and
login again.

How simply disallow this resend, and redirect him in the

new line characters / ElementSupport.encodeHtml()

2009-06-25T19:40:17Z

Hi Geert!

ElementSupport.encodeHtml(Stri ng) method does not encode new line
characters to <br/>.
Could you recommend some other encoding method from rife api in case
of new line characters ?

Best regards,
Michael.

Re: POST request / validation of page reloading.

2009-06-18T21:23:09Z

Hi Geert!

My response is late but thanks for your answers.

Best regards,
Michael.

processContext - locking exception

2009-06-05T21:02:27Z

Hi Geert!

We have in the exception stack below line:

com.uwyn.rife.engine.ElementCo ntext.processContext(ElementCo ntext.java:
460) - locked <0xd5f37638>

It could be very helpfull to provide us some hints what can be the
cause of the above "lock"?
I mean what conditions can generate such a state of processContext

Re: [rife-users] Re: Best practice to run threads from processElement

2009-06-01T18:11:50Z

I think the users guide has some examples and you'll definitely find
some in the open-source projects that are built on top of RIFE, like
Drone:
[link]

--
Geert Bevin
Terracotta - [link]
Uwyn "Use what you need" - [link]
RIFE Java application framework - [link]

Re: [rife-users] Re: Best practice to run threads from processElement

2009-06-01T18:03:38Z

Hi Geert,

Maybe I should implement one just for exercising rife ;).

Are there any docs available on how to implement and use participants ?

Ciao
Matze

Geert Bevin schrieb:

Re: [rife-users] Re: Best practice to run threads from processElement

2009-05-31T18:44:14Z

Hi Matze,
Participants give you an application-wide thread that you can easily
access from a single repository. For there rest, there are other
advantages, like exposing results and waiting for objects from other
participants to create a kind of automating dependency management, but
I don't think this would benefit you.

Re: [rife-users] Re: Best practice to run threads from processElement

2009-05-29T14:48:56Z

Hi Geert,

I need a dispatcher thread that collects packaging orders and than
starts for everey order a packing thread.
The Queue/Processing skeleton is already implemented. Though, I think I
will give a try for the participant or do you think that this
have some disadvantages that your approach does not have ?