Dynamic Menu

[Austin Coose]

Hello,

Again, as I have stated, I still trying to learn not just RIFE, but  
also programming. So, I apologize in advance if I am missing  
something obvious.

I have been able to accomplish many things with RIFE, actually more  
sophisticated than I thought possible so soon.

Anyhow, enough of that, I was working on an application and wanting  
to have the menu controlled through the back-end (in this case set up  
with RIFE-crud), to be able to set up the order, sub navigation, etc.  
on the fly;  also the global navigation with a sub-navigation menu  
based on the user, and main section. Of course, this could be divided  
into further divisions.

I have worked through many issues recently, but feel stuck on this one.

After reading the javadocs, and viewing the Wiki, would this be a  
good case for  ValueRenderer interface?

The menu as an element definitely caused problems and I was unsure  
which direction to take.

But, then again, maybe I am trying to reduce, or divide up the code  
into to too many pieces ( I do not know, just a guess.)

Would it make sense to have the menu element embedded and then  
process the element in all other implementations?

I believe I understand the exits, flowlinks, datalinks, etc. but are  
there any things to take into consideration?

Any information would be greatly appreciated. Thanks in advance.

-Austin






--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "rife-users" group.
To post to this group, send email to rife-users@...
To unsubscribe from this group, send email to rife-users-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rife-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Geert Bevin]

Hi Austin,

my main question here is, which parts of your site is this menu  
referring to? Usually, menus like this refer to directly accessible  
pages without any state that is transferred amongst menu items, is  
this the case for you? Also, are the menu items referring to pure  
content pages (like a CMS) or are they referring to more elaborate  
elements, or both?

A lot is possible, the most advanced approach is actually having a  
part of your site-structure being generated on the fly from the  
database (as a sub-site) and introspecting this structure from within  
an embedded element to create the menu from the available exits,  
using a template blueprint.

I can detail more about this once I know what your purpose it (since  
there are various degrees of complexity that can be applied here).

One thing to note already though is that you don't need to explicitly  
process embedded elements like this. The simply fact of putting an  
ELEMENT:id value tag in your template, will cause the embedded  
element to be execute in-place. Explicitly processing embedded  
elements is useful when they have a 'late' priority and you want to  
control the exact moment when they are executed.

Take care,

Geert


On 17 Sep 2007, at 21:37, Austin Coose wrote:

>
> Hello,
>
> Again, as I have stated, I still trying to learn not just RIFE, but
> also programming. So, I apologize in advance if I am missing
> something obvious.
>
> I have been able to accomplish many things with RIFE, actually more
> sophisticated than I thought possible so soon.
>
> Anyhow, enough of that, I was working on an application and wanting
> to have the menu controlled through the back-end (in this case set up
> with RIFE-crud), to be able to set up the order, sub navigation, etc.
> on the fly;  also the global navigation with a sub-navigation menu
> based on the user, and main section. Of course, this could be divided
> into further divisions.
>
> I have worked through many issues recently, but feel stuck on this  
> one.
>
> After reading the javadocs, and viewing the Wiki, would this be a
> good case for  ValueRenderer interface?
>
> The menu as an element definitely caused problems and I was unsure
> which direction to take.
>
> But, then again, maybe I am trying to reduce, or divide up the code
> into to too many pieces ( I do not know, just a guess.)
>
> Would it make sense to have the menu element embedded and then
> process the element in all other implementations?
>
> I believe I understand the exits, flowlinks, datalinks, etc. but are
> there any things to take into consideration?
>
> Any information would be greatly appreciated. Thanks in advance.
>
> -Austin
>
>
>
>
>
>
> >

--
Geert Bevin
Terracotta - http://www.terracotta.org
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "rife-users" group.
To post to this group, send email to rife-users@...
To unsubscribe from this group, send email to rife-users-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rife-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Austin Coose]

Hello Geert,

I will attempt to explain some of things that I was working towards,  
though not necessarily working on all of these ideas right now.

As I have used RIFE more and more, and have studied general java  
programming, I suppose it is only natural to think about all of  
things that are possible, but I was trying to start small, but things  
always seem to grow as I think I understand.

So, to start, yes, my first attempts have been with menus that refer  
to directly accessible pages without state that is transferred and  
pure content pages.

Still, I would like to be able to generate menu items on the fly for  
a number of reasons, and I will give just a few below.

My vision, at some point in the future, was to work towards some more  
elaborate navigation schemas that are based on user privileges,  
account status, etc.

An example:
Someone would be able to fill out a Risk Assessment Questionnaire  
(RAQ), a few questions per page. If they have not yet signed up for  
an account, then they would be asked to enter an e-mail address,  
provide a password, and answer a couple of questions; such as, do  
they currently have an advisor, a yes answer would give them a drop  
down list, and of course, if they select other,
the ability to  type in some text, drop down box for liquid net  
worth, total net worth, current amount of assets invested in  
securities, annual income, age and an option to pre-select their self-
perceived level of risk.

After taking down this basic information, based on the answers, the  
RAQ may have a few more or less questions, links to specific services  
and information geared toward the prospective clients classification  
would be in the sub-navigation menus, and after they have completed  
the risk profile, not only may this change the links displayed in the  
menus, but also the ability to view and print (or export to pdf) a  
copy of their answers with a brief explanation, and the ability to  
have a detailed report of their answers and questions and more  
information about the structure of the test, what each classification  
means, comparison of their self-perceived level and where the little  
test would characterize them, etc. This can be done once per account,  
if the user would like to re-test, then the a link to "reset", with  
an are you sure and some information about how they can print, etc.

I would like to be able to save the state if the user happens to time  
out or if the user navigates away from the page and then returns, and  
a link that on the page that simply may state "Finish Risk Profile"

As for user privileges, for users that have an account, they have the  
ability to view account statements, etc. on our brokerage partner's  
website. But, we have many announcements, paperwork that is updated  
biannually, etc, items specific to our firm. So,  say a user receives  
an e-mail about an offer letter we would like to log on and answer a  
few questions for our records about this that and the other. After  
they log on, an announcements link that is important, an explanation,  
and a link at the side that takes them to the little form for them to  
complete, all of this for those may have signed without the e-mail,  
and a link immediately available for those that the process is old  
hat, and then once it is completed,  the link in menu disappears.

Also, if someone first completes information on a contact us page,  
some of the information would be the same for someone just wanting to  
take the Risk Assessment Questionnaire, passing this along would be  
beneficial, whether the information is completed on either page, pass  
it to the other one.

And, we may want all existing clients that have not completed an RAQ  
to complete one, and that would be in a navigation box, or menu item,  
etc. when they sign on, and then disappear and show up as completed  
and the date under their profile, with the ability to view and print,  
etc as mentioned previously.

To be able to "toggle" certain services on and off as they pertain to  
strategic partner offerings, etc, etc,

I could continue for much longer, and I have already been long-
winded, for that I apologize. I thought I would give you some details  
about where I am trying to go. I understand that I must crawl before  
I walk, walk before I run, etc., but thought that it may help you  
give me some direction.

Sometimes it all seems so clear, I believe it is because I can  
conceptualize how things will work together, and as I stated  
previously, I  have been able to do some things already that I was  
pleasantly surprised with my progress; still, at other times, it  
seems I do not know even where to begin with the actual  
implementation of the code and the framework, etc.  So, then I just  
read more and more, and then try things out. etc.

Thanks in advance. I appreciate your help.

-Austin



On Sep 17, 2007, at 11:14 PM, Geert Bevin wrote:

>
> Hi Austin,
>
> my main question here is, which parts of your site is this menu
> referring to? Usually, menus like this refer to directly accessible
> pages without any state that is transferred amongst menu items, is
> this the case for you? Also, are the menu items referring to pure
> content pages (like a CMS) or are they referring to more elaborate
> elements, or both?
>
> A lot is possible, the most advanced approach is actually having a
> part of your site-structure being generated on the fly from the
> database (as a sub-site) and introspecting this structure from within
> an embedded element to create the menu from the available exits,
> using a template blueprint.
>
> I can detail more about this once I know what your purpose it (since
> there are various degrees of complexity that can be applied here).
>
> One thing to note already though is that you don't need to explicitly
> process embedded elements like this. The simply fact of putting an
> ELEMENT:id value tag in your template, will cause the embedded
> element to be execute in-place. Explicitly processing embedded
> elements is useful when they have a 'late' priority and you want to
> control the exact moment when they are executed.
>
> Take care,
>
> Geert
>
>
> On 17 Sep 2007, at 21:37, Austin Coose wrote:
>
>>
>> Hello,
>>
>> Again, as I have stated, I still trying to learn not just RIFE, but
>> also programming. So, I apologize in advance if I am missing
>> something obvious.
>>
>> I have been able to accomplish many things with RIFE, actually more
>> sophisticated than I thought possible so soon.
>>
>> Anyhow, enough of that, I was working on an application and wanting
>> to have the menu controlled through the back-end (in this case set up
>> with RIFE-crud), to be able to set up the order, sub navigation, etc.
>> on the fly;  also the global navigation with a sub-navigation menu
>> based on the user, and main section. Of course, this could be divided
>> into further divisions.
>>
>> I have worked through many issues recently, but feel stuck on this
>> one.
>>
>> After reading the javadocs, and viewing the Wiki, would this be a
>> good case for  ValueRenderer interface?
>>
>> The menu as an element definitely caused problems and I was unsure
>> which direction to take.
>>
>> But, then again, maybe I am trying to reduce, or divide up the code
>> into to too many pieces ( I do not know, just a guess.)
>>
>> Would it make sense to have the menu element embedded and then
>> process the element in all other implementations?
>>
>> I believe I understand the exits, flowlinks, datalinks, etc. but are
>> there any things to take into consideration?
>>
>> Any information would be greatly appreciated. Thanks in advance.
>>
>> -Austin
>>
>>
>>
>>
>>
>>
>>>
>
> --
> Geert Bevin
> Terracotta - http://www.terracotta.org
> Uwyn "Use what you need" - http://uwyn.com
> RIFE Java application framework - http://rifers.org
> Music and words - http://gbevin.com
>
>
> >

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "rife-users" group.
To post to this group, send email to rife-users@...
To unsubscribe from this group, send email to rife-users-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rife-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Austin Coose]

Hello Geert,

I will attempt to explain some of things that I was working towards,
though not necessarily working on all of these ideas right now.

As I have used RIFE more and more, and have studied general java
programming, I suppose it is only natural to think about all of
things that are possible, but I was trying to start small, but things
always seem to grow as I think I understand.

So, to start, yes, my first attempts have been with menus that refer
to directly accessible pages without state that is transferred and
pure content pages.

Still, I would like to be able to generate menu items on the fly for
a number of reasons, and I will give just a few below.

My vision, at some point in the future, was to work towards some more
elaborate navigation schemas that are based on user privileges,
account status, etc.

An example:
Someone would be able to fill out a Risk Assessment Questionnaire
(RAQ), a few questions per page. If they have not yet signed up for
an account, then they would be asked to enter an e-mail address,
provide a password, and answer a couple of questions; such as, do
they currently have an advisor, a yes answer would give them a drop
down list, and of course, if they select other,
the ability to  type in some text, drop down box for liquid net
worth, total net worth, current amount of assets invested in
securities, annual income, age and an option to pre-select their self-
perceived level of risk.

After taking down this basic information, based on the answers, the
RAQ may have a few more or less questions, links to specific services
and information geared toward the prospective clients classification
would be in the sub-navigation menus, and after they have completed
the risk profile, not only may this change the links displayed in the
menus, but also the ability to view and print (or export to pdf) a
copy of their answers with a brief explanation, and the ability to
have a detailed report of their answers and questions and more
information about the structure of the test, what each classification
means, comparison of their self-perceived level and where the little
test would characterize them, etc. This can be done once per account,
if the user would like to re-test, then the a link to "reset", with
an are you sure and some information about how they can print, etc.

I would like to be able to save the state if the user happens to time
out or if the user navigates away from the page and then returns, and
a link that on the page that simply may state "Finish Risk Profile"

As for user privileges, for users that have an account, they have the
ability to view account statements, etc. on our brokerage partner's
website. But, we have many announcements, paperwork that is updated
biannually, etc, items specific to our firm. So,  say a user receives
an e-mail about an offer letter we would like to log on and answer a
few questions for our records about this that and the other. After
they log on, an announcements link that is important, an explanation,
and a link at the side that takes them to the little form for them to
complete, all of this for those may have signed without the e-mail,
and a link immediately available for those that the process is old
hat, and then once it is completed,  the link in menu disappears.

Also, if someone first completes information on a contact us page,
some of the information would be the same for someone just wanting to
take the Risk Assessment Questionnaire, passing this along would be
beneficial, whether the information is completed on either page, pass
it to the other one.

And, we may want all existing clients that have not completed an RAQ
to complete one, and that would be in a navigation box, or menu item,
etc. when they sign on, and then disappear and show up as completed
and the date under their profile, with the ability to view and print,
etc as mentioned previously.

To be able to "toggle" certain services on and off as they pertain to
strategic partner offerings, etc, etc,

I could continue for much longer, and I have already been long-
winded, for that I apologize. I thought I would give you some details
about where I am trying to go. I understand that I must crawl before
I walk, walk before I run, etc., but thought that it may help you
give me some direction.

Sometimes it all seems so clear, I believe it is because I can
conceptualize how things will work together, and as I stated
previously, I  have been able to do some things already that I was
pleasantly surprised with my progress; still, at other times, it
seems I do not know even where to begin with the actual
implementation of the code and the framework, etc.  So, then I just
read more and more, and then try things out. etc.

Thanks in advance. I appreciate your help.

-Austin


On Sep 17, 2007, at 11:14 PM, Geert Bevin wrote:

>
> Hi Austin,
>
> my main question here is, which parts of your site is this menu
> referring to? Usually, menus like this refer to directly accessible
> pages without any state that is transferred amongst menu items, is
> this the case for you? Also, are the menu items referring to pure
> content pages (like a CMS) or are they referring to more elaborate
> elements, or both?
>
> A lot is possible, the most advanced approach is actually having a
> part of your site-structure being generated on the fly from the
> database (as a sub-site) and introspecting this structure from within
> an embedded element to create the menu from the available exits,
> using a template blueprint.
>
> I can detail more about this once I know what your purpose it (since
> there are various degrees of complexity that can be applied here).
>
> One thing to note already though is that you don't need to explicitly
> process embedded elements like this. The simply fact of putting an
> ELEMENT:id value tag in your template, will cause the embedded
> element to be execute in-place. Explicitly processing embedded
> elements is useful when they have a 'late' priority and you want to
> control the exact moment when they are executed.
>
> Take care,
>
> Geert
>
>
> On 17 Sep 2007, at 21:37, Austin Coose wrote:
>
>>
>> Hello,
>>
>> Again, as I have stated, I still trying to learn not just RIFE, but
>> also programming. So, I apologize in advance if I am missing
>> something obvious.
>>
>> I have been able to accomplish many things with RIFE, actually more
>> sophisticated than I thought possible so soon.
>>
>> Anyhow, enough of that, I was working on an application and wanting
>> to have the menu controlled through the back-end (in this case set up
>> with RIFE-crud), to be able to set up the order, sub navigation, etc.
>> on the fly;  also the global navigation with a sub-navigation menu
>> based on the user, and main section. Of course, this could be divided
>> into further divisions.
>>
>> I have worked through many issues recently, but feel stuck on this
>> one.
>>
>> After reading the javadocs, and viewing the Wiki, would this be a
>> good case for  ValueRenderer interface?
>>
>> The menu as an element definitely caused problems and I was unsure
>> which direction to take.
>>
>> But, then again, maybe I am trying to reduce, or divide up the code
>> into to too many pieces ( I do not know, just a guess.)
>>
>> Would it make sense to have the menu element embedded and then
>> process the element in all other implementations?
>>
>> I believe I understand the exits, flowlinks, datalinks, etc. but are
>> there any things to take into consideration?
>>
>> Any information would be greatly appreciated. Thanks in advance.
>>
>> -Austin
>>
>>
>>
>>
>>
>>
>>>
>
> --
> Geert Bevin
> Terracotta - http://www.terracotta.org
> Uwyn "Use what you need" - http://uwyn.com
> RIFE Java application framework - http://rifers.org
> Music and words - http://gbevin.com
>
>
> >

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "rife-users" group.
To post to this group, send email to rife-users@...
To unsubscribe from this group, send email to rife-users-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rife-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Geert Bevin]

Hi Austin,

your description here sounds like a collection of functional, well-
defined elements that you conditionally want to link to based on  
certain criteria and at different locations in the page.

Basically, flowlinks, datalinks (and thus autolinks) and most  
certainly globalexits should do all you need. Since your application  
flow is well defined, RIFE's site structure is a perfect fit. You can  
then use the regular EXIT:QUERY:exit value tags for instance, and put  
those into blocks. You can choose to explicitly display those blocks  
from within your elements, or use blockvalue scripting to move that  
decision to your templates. If appropriate, parts of this, or all of  
it can be bundled in an embedded element. You could for example  
create embedded elements that initially check the conditions that are  
required, and if these are not met, nothing would be printed out. You  
could even create those embedded elements without that conditional  
logic, and create a set of 'condition' elements that are inherited by  
the embedded elements (RIFE's site structure 'inherits') and only  
call 'child()' when the condition is true.

I hope this makes sense, if some things aren't clear you should be  
able to search the wiki for certain terms.

Take care,

Geert

On 18 Sep 2007, at 07:55, Austin Coose wrote:

>
> Hello Geert,
>
> I will attempt to explain some of things that I was working towards,
> though not necessarily working on all of these ideas right now.
>
> As I have used RIFE more and more, and have studied general java
> programming, I suppose it is only natural to think about all of
> things that are possible, but I was trying to start small, but things
> always seem to grow as I think I understand.
>
> So, to start, yes, my first attempts have been with menus that refer
> to directly accessible pages without state that is transferred and
> pure content pages.
>
> Still, I would like to be able to generate menu items on the fly for
> a number of reasons, and I will give just a few below.
>
> My vision, at some point in the future, was to work towards some more
> elaborate navigation schemas that are based on user privileges,
> account status, etc.
>
> An example:
> Someone would be able to fill out a Risk Assessment Questionnaire
> (RAQ), a few questions per page. If they have not yet signed up for
> an account, then they would be asked to enter an e-mail address,
> provide a password, and answer a couple of questions; such as, do
> they currently have an advisor, a yes answer would give them a drop
> down list, and of course, if they select other,
> the ability to  type in some text, drop down box for liquid net
> worth, total net worth, current amount of assets invested in
> securities, annual income, age and an option to pre-select their self-
> perceived level of risk.
>
> After taking down this basic information, based on the answers, the
> RAQ may have a few more or less questions, links to specific services
> and information geared toward the prospective clients classification
> would be in the sub-navigation menus, and after they have completed
> the risk profile, not only may this change the links displayed in the
> menus, but also the ability to view and print (or export to pdf) a
> copy of their answers with a brief explanation, and the ability to
> have a detailed report of their answers and questions and more
> information about the structure of the test, what each classification
> means, comparison of their self-perceived level and where the little
> test would characterize them, etc. This can be done once per account,
> if the user would like to re-test, then the a link to "reset", with
> an are you sure and some information about how they can print, etc.
>
> I would like to be able to save the state if the user happens to time
> out or if the user navigates away from the page and then returns, and
> a link that on the page that simply may state "Finish Risk Profile"
>
> As for user privileges, for users that have an account, they have the
> ability to view account statements, etc. on our brokerage partner's
> website. But, we have many announcements, paperwork that is updated
> biannually, etc, items specific to our firm. So,  say a user receives
> an e-mail about an offer letter we would like to log on and answer a
> few questions for our records about this that and the other. After
> they log on, an announcements link that is important, an explanation,
> and a link at the side that takes them to the little form for them to
> complete, all of this for those may have signed without the e-mail,
> and a link immediately available for those that the process is old
> hat, and then once it is completed,  the link in menu disappears.
>
> Also, if someone first completes information on a contact us page,
> some of the information would be the same for someone just wanting to
> take the Risk Assessment Questionnaire, passing this along would be
> beneficial, whether the information is completed on either page, pass
> it to the other one.
>
> And, we may want all existing clients that have not completed an RAQ
> to complete one, and that would be in a navigation box, or menu item,
> etc. when they sign on, and then disappear and show up as completed
> and the date under their profile, with the ability to view and print,
> etc as mentioned previously.
>
> To be able to "toggle" certain services on and off as they pertain to
> strategic partner offerings, etc, etc,
>
> I could continue for much longer, and I have already been long-
> winded, for that I apologize. I thought I would give you some details
> about where I am trying to go. I understand that I must crawl before
> I walk, walk before I run, etc., but thought that it may help you
> give me some direction.
>
> Sometimes it all seems so clear, I believe it is because I can
> conceptualize how things will work together, and as I stated
> previously, I  have been able to do some things already that I was
> pleasantly surprised with my progress; still, at other times, it
> seems I do not know even where to begin with the actual
> implementation of the code and the framework, etc.  So, then I just
> read more and more, and then try things out. etc.
>
> Thanks in advance. I appreciate your help.
>
> -Austin
>
>
>
> On Sep 17, 2007, at 11:14 PM, Geert Bevin wrote:
>
>>
>> Hi Austin,
>>
>> my main question here is, which parts of your site is this menu
>> referring to? Usually, menus like this refer to directly accessible
>> pages without any state that is transferred amongst menu items, is
>> this the case for you? Also, are the menu items referring to pure
>> content pages (like a CMS) or are they referring to more elaborate
>> elements, or both?
>>
>> A lot is possible, the most advanced approach is actually having a
>> part of your site-structure being generated on the fly from the
>> database (as a sub-site) and introspecting this structure from within
>> an embedded element to create the menu from the available exits,
>> using a template blueprint.
>>
>> I can detail more about this once I know what your purpose it (since
>> there are various degrees of complexity that can be applied here).
>>
>> One thing to note already though is that you don't need to explicitly
>> process embedded elements like this. The simply fact of putting an
>> ELEMENT:id value tag in your template, will cause the embedded
>> element to be execute in-place. Explicitly processing embedded
>> elements is useful when they have a 'late' priority and you want to
>> control the exact moment when they are executed.
>>
>> Take care,
>>
>> Geert
>>
>>
>> On 17 Sep 2007, at 21:37, Austin Coose wrote:
>>
>>>
>>> Hello,
>>>
>>> Again, as I have stated, I still trying to learn not just RIFE, but
>>> also programming. So, I apologize in advance if I am missing
>>> something obvious.
>>>
>>> I have been able to accomplish many things with RIFE, actually more
>>> sophisticated than I thought possible so soon.
>>>
>>> Anyhow, enough of that, I was working on an application and wanting
>>> to have the menu controlled through the back-end (in this case  
>>> set up
>>> with RIFE-crud), to be able to set up the order, sub navigation,  
>>> etc.
>>> on the fly;  also the global navigation with a sub-navigation menu
>>> based on the user, and main section. Of course, this could be  
>>> divided
>>> into further divisions.
>>>
>>> I have worked through many issues recently, but feel stuck on this
>>> one.
>>>
>>> After reading the javadocs, and viewing the Wiki, would this be a
>>> good case for  ValueRenderer interface?
>>>
>>> The menu as an element definitely caused problems and I was unsure
>>> which direction to take.
>>>
>>> But, then again, maybe I am trying to reduce, or divide up the code
>>> into to too many pieces ( I do not know, just a guess.)
>>>
>>> Would it make sense to have the menu element embedded and then
>>> process the element in all other implementations?
>>>
>>> I believe I understand the exits, flowlinks, datalinks, etc. but are
>>> there any things to take into consideration?
>>>
>>> Any information would be greatly appreciated. Thanks in advance.
>>>
>>> -Austin
>>>
>>>
>>>
>>>
>>>
>>>
>>>>
>>
>> --
>> Geert Bevin
>> Terracotta - http://www.terracotta.org
>> Uwyn "Use what you need" - http://uwyn.com
>> RIFE Java application framework - http://rifers.org
>> Music and words - http://gbevin.com
>>
>>
>>>
>
>
> >

--
Geert Bevin
Terracotta - http://www.terracotta.org
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "rife-users" group.
To post to this group, send email to rife-users@...
To unsubscribe from this group, send email to rife-users-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rife-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Austin Coose]

Geert,

Thanks for your response. Your first response when you wrote,

>>> you don't need to explicitly
>>> process embedded elements like this

  made a big difference. I was screwing it up with blocks and values  
and things were not getting printed out properly.
Things make more sense now.

Thanks for all the hard work and taking the time to respond.

Good Luck with the lasik as well, I had the same surgery done a few  
years ago and I love it!

That first month with no eye-rubbing, dry eyes, no submerging  
underwater, etc. certainly sucks, but, hey, 30 days of annoyance for  
a lifetime of no glasses/contacts is sure worth it.

Hope your recovery goes well.


-Austin


On Sep 18, 2007, at 11:53 AM, Geert Bevin wrote:

>
> Hi Austin,
>
> your description here sounds like a collection of functional, well-
> defined elements that you conditionally want to link to based on
> certain criteria and at different locations in the page.
>
> Basically, flowlinks, datalinks (and thus autolinks) and most
> certainly globalexits should do all you need. Since your application
> flow is well defined, RIFE's site structure is a perfect fit. You can
> then use the regular EXIT:QUERY:exit value tags for instance, and put
> those into blocks. You can choose to explicitly display those blocks
> from within your elements, or use blockvalue scripting to move that
> decision to your templates. If appropriate, parts of this, or all of
> it can be bundled in an embedded element. You could for example
> create embedded elements that initially check the conditions that are
> required, and if these are not met, nothing would be printed out. You
> could even create those embedded elements without that conditional
> logic, and create a set of 'condition' elements that are inherited by
> the embedded elements (RIFE's site structure 'inherits') and only
> call 'child()' when the condition is true.
>
> I hope this makes sense, if some things aren't clear you should be
> able to search the wiki for certain terms.
>
> Take care,
>
> Geert
>
> On 18 Sep 2007, at 07:55, Austin Coose wrote:
>
>>
>> Hello Geert,
>>
>> I will attempt to explain some of things that I was working towards,
>> though not necessarily working on all of these ideas right now.
>>
>> As I have used RIFE more and more, and have studied general java
>> programming, I suppose it is only natural to think about all of
>> things that are possible, but I was trying to start small, but things
>> always seem to grow as I think I understand.
>>
>> So, to start, yes, my first attempts have been with menus that refer
>> to directly accessible pages without state that is transferred and
>> pure content pages.
>>
>> Still, I would like to be able to generate menu items on the fly for
>> a number of reasons, and I will give just a few below.
>>
>> My vision, at some point in the future, was to work towards some more
>> elaborate navigation schemas that are based on user privileges,
>> account status, etc.
>>
>> An example:
>> Someone would be able to fill out a Risk Assessment Questionnaire
>> (RAQ), a few questions per page. If they have not yet signed up for
>> an account, then they would be asked to enter an e-mail address,
>> provide a password, and answer a couple of questions; such as, do
>> they currently have an advisor, a yes answer would give them a drop
>> down list, and of course, if they select other,
>> the ability to  type in some text, drop down box for liquid net
>> worth, total net worth, current amount of assets invested in
>> securities, annual income, age and an option to pre-select their  
>> self-
>> perceived level of risk.
>>
>> After taking down this basic information, based on the answers, the
>> RAQ may have a few more or less questions, links to specific services
>> and information geared toward the prospective clients classification
>> would be in the sub-navigation menus, and after they have completed
>> the risk profile, not only may this change the links displayed in the
>> menus, but also the ability to view and print (or export to pdf) a
>> copy of their answers with a brief explanation, and the ability to
>> have a detailed report of their answers and questions and more
>> information about the structure of the test, what each classification
>> means, comparison of their self-perceived level and where the little
>> test would characterize them, etc. This can be done once per account,
>> if the user would like to re-test, then the a link to "reset", with
>> an are you sure and some information about how they can print, etc.
>>
>> I would like to be able to save the state if the user happens to time
>> out or if the user navigates away from the page and then returns, and
>> a link that on the page that simply may state "Finish Risk Profile"
>>
>> As for user privileges, for users that have an account, they have the
>> ability to view account statements, etc. on our brokerage partner's
>> website. But, we have many announcements, paperwork that is updated
>> biannually, etc, items specific to our firm. So,  say a user receives
>> an e-mail about an offer letter we would like to log on and answer a
>> few questions for our records about this that and the other. After
>> they log on, an announcements link that is important, an explanation,
>> and a link at the side that takes them to the little form for them to
>> complete, all of this for those may have signed without the e-mail,
>> and a link immediately available for those that the process is old
>> hat, and then once it is completed,  the link in menu disappears.
>>
>> Also, if someone first completes information on a contact us page,
>> some of the information would be the same for someone just wanting to
>> take the Risk Assessment Questionnaire, passing this along would be
>> beneficial, whether the information is completed on either page, pass
>> it to the other one.
>>
>> And, we may want all existing clients that have not completed an RAQ
>> to complete one, and that would be in a navigation box, or menu item,
>> etc. when they sign on, and then disappear and show up as completed
>> and the date under their profile, with the ability to view and print,
>> etc as mentioned previously.
>>
>> To be able to "toggle" certain services on and off as they pertain to
>> strategic partner offerings, etc, etc,
>>
>> I could continue for much longer, and I have already been long-
>> winded, for that I apologize. I thought I would give you some details
>> about where I am trying to go. I understand that I must crawl before
>> I walk, walk before I run, etc., but thought that it may help you
>> give me some direction.
>>
>> Sometimes it all seems so clear, I believe it is because I can
>> conceptualize how things will work together, and as I stated
>> previously, I  have been able to do some things already that I was
>> pleasantly surprised with my progress; still, at other times, it
>> seems I do not know even where to begin with the actual
>> implementation of the code and the framework, etc.  So, then I just
>> read more and more, and then try things out. etc.
>>
>> Thanks in advance. I appreciate your help.
>>
>> -Austin
>>
>>
>>
>> On Sep 17, 2007, at 11:14 PM, Geert Bevin wrote:
>>
>>>
>>> Hi Austin,
>>>
>>> my main question here is, which parts of your site is this menu
>>> referring to? Usually, menus like this refer to directly accessible
>>> pages without any state that is transferred amongst menu items, is
>>> this the case for you? Also, are the menu items referring to pure
>>> content pages (like a CMS) or are they referring to more elaborate
>>> elements, or both?
>>>
>>> A lot is possible, the most advanced approach is actually having a
>>> part of your site-structure being generated on the fly from the
>>> database (as a sub-site) and introspecting this structure from  
>>> within
>>> an embedded element to create the menu from the available exits,
>>> using a template blueprint.
>>>
>>> I can detail more about this once I know what your purpose it (since
>>> there are various degrees of complexity that can be applied here).
>>>
>>> One thing to note already though is that you don't need to  
>>> explicitly
>>> process embedded elements like this. The simply fact of putting an
>>> ELEMENT:id value tag in your template, will cause the embedded
>>> element to be execute in-place. Explicitly processing embedded
>>> elements is useful when they have a 'late' priority and you want to
>>> control the exact moment when they are executed.
>>>
>>> Take care,
>>>
>>> Geert
>>>
>>>
>>> On 17 Sep 2007, at 21:37, Austin Coose wrote:
>>>
>>>>
>>>> Hello,
>>>>
>>>> Again, as I have stated, I still trying to learn not just RIFE, but
>>>> also programming. So, I apologize in advance if I am missing
>>>> something obvious.
>>>>
>>>> I have been able to accomplish many things with RIFE, actually more
>>>> sophisticated than I thought possible so soon.
>>>>
>>>> Anyhow, enough of that, I was working on an application and wanting
>>>> to have the menu controlled through the back-end (in this case
>>>> set up
>>>> with RIFE-crud), to be able to set up the order, sub navigation,
>>>> etc.
>>>> on the fly;  also the global navigation with a sub-navigation menu
>>>> based on the user, and main section. Of course, this could be
>>>> divided
>>>> into further divisions.
>>>>
>>>> I have worked through many issues recently, but feel stuck on this
>>>> one.
>>>>
>>>> After reading the javadocs, and viewing the Wiki, would this be a
>>>> good case for  ValueRenderer interface?
>>>>
>>>> The menu as an element definitely caused problems and I was unsure
>>>> which direction to take.
>>>>
>>>> But, then again, maybe I am trying to reduce, or divide up the code
>>>> into to too many pieces ( I do not know, just a guess.)
>>>>
>>>> Would it make sense to have the menu element embedded and then
>>>> process the element in all other implementations?
>>>>
>>>> I believe I understand the exits, flowlinks, datalinks, etc. but  
>>>> are
>>>> there any things to take into consideration?
>>>>
>>>> Any information would be greatly appreciated. Thanks in advance.
>>>>
>>>> -Austin
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>
>>> --
>>> Geert Bevin
>>> Terracotta - http://www.terracotta.org
>>> Uwyn "Use what you need" - http://uwyn.com
>>> RIFE Java application framework - http://rifers.org
>>> Music and words - http://gbevin.com
>>>
>>>
>>>>
>>
>>
>>>
>
> --
> Geert Bevin
> Terracotta - http://www.terracotta.org
> Uwyn "Use what you need" - http://uwyn.com
> RIFE Java application framework - http://rifers.org
> Music and words - http://gbevin.com
>
>
> >

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "rife-users" group.
To post to this group, send email to rife-users@...
To unsubscribe from this group, send email to rife-users-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rife-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Geert Bevin]

Hi Austin,

nice the hear that my suggestions were of some help.

Still getting used to my new sight and my near vision is not totally  
stable yet (my brain seems to have a bit of trouble to maintain  
focus). It should improve in the coming days.

Take care,

Geert

On 20 Sep 2007, at 19:14, Austin Coose wrote:

>
> Geert,
>
> Thanks for your response. Your first response when you wrote,
>
>>>> you don't need to explicitly
>>>> process embedded elements like this
>
>   made a big difference. I was screwing it up with blocks and values
> and things were not getting printed out properly.
> Things make more sense now.
>
> Thanks for all the hard work and taking the time to respond.
>
> Good Luck with the lasik as well, I had the same surgery done a few
> years ago and I love it!
>
> That first month with no eye-rubbing, dry eyes, no submerging
> underwater, etc. certainly sucks, but, hey, 30 days of annoyance for
> a lifetime of no glasses/contacts is sure worth it.
>
> Hope your recovery goes well.
>
>
> -Austin
>
>
> On Sep 18, 2007, at 11:53 AM, Geert Bevin wrote:
>
>>
>> Hi Austin,
>>
>> your description here sounds like a collection of functional, well-
>> defined elements that you conditionally want to link to based on
>> certain criteria and at different locations in the page.
>>
>> Basically, flowlinks, datalinks (and thus autolinks) and most
>> certainly globalexits should do all you need. Since your application
>> flow is well defined, RIFE's site structure is a perfect fit. You can
>> then use the regular EXIT:QUERY:exit value tags for instance, and put
>> those into blocks. You can choose to explicitly display those blocks
>> from within your elements, or use blockvalue scripting to move that
>> decision to your templates. If appropriate, parts of this, or all of
>> it can be bundled in an embedded element. You could for example
>> create embedded elements that initially check the conditions that are
>> required, and if these are not met, nothing would be printed out. You
>> could even create those embedded elements without that conditional
>> logic, and create a set of 'condition' elements that are inherited by
>> the embedded elements (RIFE's site structure 'inherits') and only
>> call 'child()' when the condition is true.
>>
>> I hope this makes sense, if some things aren't clear you should be
>> able to search the wiki for certain terms.
>>
>> Take care,
>>
>> Geert
>>
>> On 18 Sep 2007, at 07:55, Austin Coose wrote:
>>
>>>
>>> Hello Geert,
>>>
>>> I will attempt to explain some of things that I was working towards,
>>> though not necessarily working on all of these ideas right now.
>>>
>>> As I have used RIFE more and more, and have studied general java
>>> programming, I suppose it is only natural to think about all of
>>> things that are possible, but I was trying to start small, but  
>>> things
>>> always seem to grow as I think I understand.
>>>
>>> So, to start, yes, my first attempts have been with menus that refer
>>> to directly accessible pages without state that is transferred and
>>> pure content pages.
>>>
>>> Still, I would like to be able to generate menu items on the fly for
>>> a number of reasons, and I will give just a few below.
>>>
>>> My vision, at some point in the future, was to work towards some  
>>> more
>>> elaborate navigation schemas that are based on user privileges,
>>> account status, etc.
>>>
>>> An example:
>>> Someone would be able to fill out a Risk Assessment Questionnaire
>>> (RAQ), a few questions per page. If they have not yet signed up for
>>> an account, then they would be asked to enter an e-mail address,
>>> provide a password, and answer a couple of questions; such as, do
>>> they currently have an advisor, a yes answer would give them a drop
>>> down list, and of course, if they select other,
>>> the ability to  type in some text, drop down box for liquid net
>>> worth, total net worth, current amount of assets invested in
>>> securities, annual income, age and an option to pre-select their
>>> self-
>>> perceived level of risk.
>>>
>>> After taking down this basic information, based on the answers, the
>>> RAQ may have a few more or less questions, links to specific  
>>> services
>>> and information geared toward the prospective clients classification
>>> would be in the sub-navigation menus, and after they have completed
>>> the risk profile, not only may this change the links displayed in  
>>> the
>>> menus, but also the ability to view and print (or export to pdf) a
>>> copy of their answers with a brief explanation, and the ability to
>>> have a detailed report of their answers and questions and more
>>> information about the structure of the test, what each  
>>> classification
>>> means, comparison of their self-perceived level and where the little
>>> test would characterize them, etc. This can be done once per  
>>> account,
>>> if the user would like to re-test, then the a link to "reset", with
>>> an are you sure and some information about how they can print, etc.
>>>
>>> I would like to be able to save the state if the user happens to  
>>> time
>>> out or if the user navigates away from the page and then returns,  
>>> and
>>> a link that on the page that simply may state "Finish Risk Profile"
>>>
>>> As for user privileges, for users that have an account, they have  
>>> the
>>> ability to view account statements, etc. on our brokerage partner's
>>> website. But, we have many announcements, paperwork that is updated
>>> biannually, etc, items specific to our firm. So,  say a user  
>>> receives
>>> an e-mail about an offer letter we would like to log on and answer a
>>> few questions for our records about this that and the other. After
>>> they log on, an announcements link that is important, an  
>>> explanation,
>>> and a link at the side that takes them to the little form for  
>>> them to
>>> complete, all of this for those may have signed without the e-mail,
>>> and a link immediately available for those that the process is old
>>> hat, and then once it is completed,  the link in menu disappears.
>>>
>>> Also, if someone first completes information on a contact us page,
>>> some of the information would be the same for someone just  
>>> wanting to
>>> take the Risk Assessment Questionnaire, passing this along would be
>>> beneficial, whether the information is completed on either page,  
>>> pass
>>> it to the other one.
>>>
>>> And, we may want all existing clients that have not completed an RAQ
>>> to complete one, and that would be in a navigation box, or menu  
>>> item,
>>> etc. when they sign on, and then disappear and show up as completed
>>> and the date under their profile, with the ability to view and  
>>> print,
>>> etc as mentioned previously.
>>>
>>> To be able to "toggle" certain services on and off as they  
>>> pertain to
>>> strategic partner offerings, etc, etc,
>>>
>>> I could continue for much longer, and I have already been long-
>>> winded, for that I apologize. I thought I would give you some  
>>> details
>>> about where I am trying to go. I understand that I must crawl before
>>> I walk, walk before I run, etc., but thought that it may help you
>>> give me some direction.
>>>
>>> Sometimes it all seems so clear, I believe it is because I can
>>> conceptualize how things will work together, and as I stated
>>> previously, I  have been able to do some things already that I was
>>> pleasantly surprised with my progress; still, at other times, it
>>> seems I do not know even where to begin with the actual
>>> implementation of the code and the framework, etc.  So, then I just
>>> read more and more, and then try things out. etc.
>>>
>>> Thanks in advance. I appreciate your help.
>>>
>>> -Austin
>>>
>>>
>>>
>>> On Sep 17, 2007, at 11:14 PM, Geert Bevin wrote:
>>>
>>>>
>>>> Hi Austin,
>>>>
>>>> my main question here is, which parts of your site is this menu
>>>> referring to? Usually, menus like this refer to directly accessible
>>>> pages without any state that is transferred amongst menu items, is
>>>> this the case for you? Also, are the menu items referring to pure
>>>> content pages (like a CMS) or are they referring to more elaborate
>>>> elements, or both?
>>>>
>>>> A lot is possible, the most advanced approach is actually having a
>>>> part of your site-structure being generated on the fly from the
>>>> database (as a sub-site) and introspecting this structure from
>>>> within
>>>> an embedded element to create the menu from the available exits,
>>>> using a template blueprint.
>>>>
>>>> I can detail more about this once I know what your purpose it  
>>>> (since
>>>> there are various degrees of complexity that can be applied here).
>>>>
>>>> One thing to note already though is that you don't need to
>>>> explicitly
>>>> process embedded elements like this. The simply fact of putting an
>>>> ELEMENT:id value tag in your template, will cause the embedded
>>>> element to be execute in-place. Explicitly processing embedded
>>>> elements is useful when they have a 'late' priority and you want to
>>>> control the exact moment when they are executed.
>>>>
>>>> Take care,
>>>>
>>>> Geert
>>>>
>>>>
>>>> On 17 Sep 2007, at 21:37, Austin Coose wrote:
>>>>
>>>>>
>>>>> Hello,
>>>>>
>>>>> Again, as I have stated, I still trying to learn not just RIFE,  
>>>>> but
>>>>> also programming. So, I apologize in advance if I am missing
>>>>> something obvious.
>>>>>
>>>>> I have been able to accomplish many things with RIFE, actually  
>>>>> more
>>>>> sophisticated than I thought possible so soon.
>>>>>
>>>>> Anyhow, enough of that, I was working on an application and  
>>>>> wanting
>>>>> to have the menu controlled through the back-end (in this case
>>>>> set up
>>>>> with RIFE-crud), to be able to set up the order, sub navigation,
>>>>> etc.
>>>>> on the fly;  also the global navigation with a sub-navigation menu
>>>>> based on the user, and main section. Of course, this could be
>>>>> divided
>>>>> into further divisions.
>>>>>
>>>>> I have worked through many issues recently, but feel stuck on this
>>>>> one.
>>>>>
>>>>> After reading the javadocs, and viewing the Wiki, would this be a
>>>>> good case for  ValueRenderer interface?
>>>>>
>>>>> The menu as an element definitely caused problems and I was unsure
>>>>> which direction to take.
>>>>>
>>>>> But, then again, maybe I am trying to reduce, or divide up the  
>>>>> code
>>>>> into to too many pieces ( I do not know, just a guess.)
>>>>>
>>>>> Would it make sense to have the menu element embedded and then
>>>>> process the element in all other implementations?
>>>>>
>>>>> I believe I understand the exits, flowlinks, datalinks, etc. but
>>>>> are
>>>>> there any things to take into consideration?
>>>>>
>>>>> Any information would be greatly appreciated. Thanks in advance.
>>>>>
>>>>> -Austin
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>
>>>> --
>>>> Geert Bevin
>>>> Terracotta - http://www.terracotta.org
>>>> Uwyn "Use what you need" - http://uwyn.com
>>>> RIFE Java application framework - http://rifers.org
>>>> Music and words - http://gbevin.com
>>>>
>>>>
>>>>>
>>>
>>>
>>>>
>>
>> --
>> Geert Bevin
>> Terracotta - http://www.terracotta.org
>> Uwyn "Use what you need" - http://uwyn.com
>> RIFE Java application framework - http://rifers.org
>> Music and words - http://gbevin.com
>>
>>
>>>
>
>
> >

--
Geert Bevin
Terracotta - http://www.terracotta.org
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "rife-users" group.
To post to this group, send email to rife-users@...
To unsubscribe from this group, send email to rife-users-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rife-users?hl=en
-~----------~----~----~----~------~----~------~--~---