date:20051222

RE: [OT] customizing JSF view management (was [shale][struts-faces] structured URLs with JSF (reprised))

2005-12-22 Thread David G. Friedman

I've also been thinking about the ViewHandler approach for a day or two but 
haven't tried anything with that yet.  Your
code is much simpler than what I'd been daydreaming/pondering in between other 
tasks today.

Regards,
David

-Original Message-
From: news [mailto:[EMAIL PROTECTED] Behalf Of Laurie Harper
Sent: Friday, December 23, 2005 12:59 AM
To: user@struts.apache.org
Subject: Re: [OT] customizing JSF view management (was
[shale][struts-faces] structured URLs with JSF (reprised))

Craig McClanahan wrote:
> On 12/22/05, Laurie Harper <[EMAIL PROTECTED]> wrote:
>> I think I've found an easier way... It looks like both our needs can be
>> met by installing a custom ViewHandler that just delegates all methods
>> to its parent, but which changes the viewId passed into createView
>> before calling super.createView:
>>
>>public class ProjectivaViewHandler extends ViewHandler {
>>  private ViewHandler parent;
>>
>>  public ProjectivaViewHandler(ViewHandler parent) {
>>this.parent = parent;
>>  }
>>
>>  public UIViewRoot createView(FacesContext ctx, String viewId) {
>>String pathToActualView = myViewLogic(viewId);
>>return super.createView(ctx, pathToActualView);
>>  }
>>
>>  ...
>>}
>>
>> In my case I'd also need to push data from the original viewId into the
>> request for use during rendering and use a custom NavigationHandler to
>> let me carry parts of the from-view-id into the to-view-id, but I don't
>> think you'd need that: just calling createView(ctx, "/somehost" +
>> viewId) would be sufficient for you.
>>
>> Craig, does this sound like a reasonable thing to be doing? It sure
>> *looks* like a solution to the problem :-)
>
>
> The view that ultimately gets created will have a view identifier (as
> returned by getFacesContext().getViewRoot().getViewId()) of the *actual*
> view that was created, not the identifier you passed in from the navigation
> rule.  As long as that's OK with your business logic, it sounds like you
> might have a reasonable solution.

Meaning that getFacesContext().getViewRoot().getViewId() will return
what I pass into super.createView (pathToActualView), not what was
passed into createView originally (viewId)?

To be honest, I don't know JSF well enough yet to understand the
consequences of that. I don't have anything yet which depends on or
calls that method, so I suspect it's OK... I've just implemented what I
described above and it certainly seem to be working for me so far; i
still have to figure out how to write a NavigationHandler that
cooperates with this scheme, though.

Sounds like I'm on the right track, I'll see how it goes tomorrow with
writing a nav handler that closes the loop.

L.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [OT] customizing JSF view management (was [shale][struts-faces] structured URLs with JSF (reprised))

2005-12-22 Thread Laurie Harper


Craig McClanahan wrote:

On 12/22/05, Laurie Harper <[EMAIL PROTECTED]> wrote:

I think I've found an easier way... It looks like both our needs can be
met by installing a custom ViewHandler that just delegates all methods
to its parent, but which changes the viewId passed into createView
before calling super.createView:

   public class ProjectivaViewHandler extends ViewHandler {
 private ViewHandler parent;

 public ProjectivaViewHandler(ViewHandler parent) {
   this.parent = parent;
 }

 public UIViewRoot createView(FacesContext ctx, String viewId) {
   String pathToActualView = myViewLogic(viewId);
   return super.createView(ctx, pathToActualView);
 }

 ...
   }

In my case I'd also need to push data from the original viewId into the
request for use during rendering and use a custom NavigationHandler to
let me carry parts of the from-view-id into the to-view-id, but I don't
think you'd need that: just calling createView(ctx, "/somehost" +
viewId) would be sufficient for you.

Craig, does this sound like a reasonable thing to be doing? It sure
*looks* like a solution to the problem :-)



The view that ultimately gets created will have a view identifier (as
returned by getFacesContext().getViewRoot().getViewId()) of the *actual*
view that was created, not the identifier you passed in from the navigation
rule.  As long as that's OK with your business logic, it sounds like you
might have a reasonable solution.


Meaning that getFacesContext().getViewRoot().getViewId() will return 
what I pass into super.createView (pathToActualView), not what was 
passed into createView originally (viewId)?


To be honest, I don't know JSF well enough yet to understand the 
consequences of that. I don't have anything yet which depends on or 
calls that method, so I suspect it's OK... I've just implemented what I 
described above and it certainly seem to be working for me so far; i 
still have to figure out how to write a NavigationHandler that 
cooperates with this scheme, though.


Sounds like I'm on the right track, I'll see how it goes tomorrow with 
writing a nav handler that closes the loop.


L.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

custom server side validation in shale

2005-12-22 Thread JEEVANATHAM P. /BPCRP/INFOTECH/VASHI

Hi all,

Please let me know about how can we do server side validation in shale. Like
user validation,

when user enters some value that time we need to check with database whether
that is correct one or not.

If not that will through a alert not message on the screen.

Regards,

JEEVANANTHAM PARAMASAMY,
Software Engineer,
3i - INFOTECH Limited,
Alwarpet,
Chennai - 600018.

Phone: 044 24678000 extn:418
Cell no: 09840933967

--
Greetings!

ICICI Infotech is now 3i Infotech.

The e-mail addresses of the company's employees have been changed to @3i-infotech.com. You are requested to take note of this new e-mail ID and
make use of the same in future

"This e-mail message may contain confidential, proprietary or legally
privileged information. It should not be used by anyone who is not the original
intended recipient. If you have erroneously received this message, please
delete it immediately and notify the sender. The recipient acknowledges that 3i
Infotech or its subsidiaries and associated companies, (collectively "3i
Infotech"), are unable to exercise control or ensure or guarantee the integrity
of/over the contents of the information contained in e-mail transmissions and
further acknowledges that any views expressed in this message are those of the
individual sender and no binding nature of the message shall be implied or
assumed unless the sender does so expressly with due authority of 3i Infotech.
Before opening any attachments please check them for viruses and defects."

50 matches

Mail list logo