Hi David,
the friend database example is missing a lot of features, most
notably data flow and logic flow. If I were you I'd split up the
elements in almost exactly the same way as you'd split up the pages.
You can then create datalinks and flowlinks between them, using exits
and inputs/outputs.
I found that the easiest way to decide upon a RIFE site structure,
was to do it on paper and draw the pages with the flow in a diagram,
something that resembles this:
http://rifers.org/wiki/display/RIFE/GuideNumberguess#GuideNumberguess-
figurenumberguesssite
Doing it like that will give you very nice encapsulated separation of
the logic, and full flexibility to rearrange or extend your flow
later on. Your templates will also be a lot cleaner since you can
easily isolate each layout.
You should look at submissions as real data submissions, typically
bounded to forms (though they don't have to be). Submissions always
submit to the active element, so typically they happen after the
render phase. When you want to leave the element, you provide outputs
and call an exit. The datalinks and flowlinks will then make the
engine decide upon the next state transition.
About the get parameters, these typically map to inputs and you get
them with the getInput* methods. Alternatively, if you have a setter
with the same property name in your element class, the values will be
automatically injected in the element instance.
The row processors are usually used as anonymous inner classes. You
can separate them out as dedicated mini-classes, but that actually
only really makes sense if you reuse the row processor elsewhere.
You're not required to use row processors though, you can fetch
everything in a list and process the entries. However, using a row
processor ensures that there's always just one entry in memory and
you can process very large lists, without any memory overhead.
I hope this helps you further along.
Best regards,
Geert
On 20-jan-06, at 11:31, David Herbert wrote:
I am trying to develop a small fault stats reporting package within
the RIFE
framework as a first proof-of-concept project. Essentially its
structure is
as follows:
page 1 - a top level overview report containing 3 tables, the
contents of
which are extracted from postgresql database tables. One of the
columns of
one of the tables contains links to page 2 of the reporting
package. I
envisage at the Java level that these will be calls to the same bit
of code
but with a GET parameter in the URL thus:
<a href="/stats?authority_id=020">xxxxx</a>
page 2 - another set of reports, 2 tables, specific to the
'authority_id'
parameter passed in above. One of the tables will contain links to
pages 3
and 4. Again, probably the same piece of code, but called thus e.g:
<a href="/stats?authority_id=020&fault_type=locality">xxxxx</a>
page 3,4 - summary tables of faults of different types specific to
'authority_id' above.
I am struggling with a few things here, chiefly how to break up the
project
into sensible RIFE elements. As I see it, there is really one
element here
which is working differently depending on GET parameters.
Accordingly I've
created a site file thus:
<site>
<arrival destid="TOP"/>
<element id="TOP" file="top.xml" url="/stats">
<submission name="getReport">
<param name="area_id">
<default>all</default>
</param>
<param name="fault_type">
<default>all</default>
</param>
</submission>
<flowlink srcexit="install" destid="INSTALL"/>
</element>
<element id="INSTALL" file="install.xml" url="/install">
<flowlink srcexit="top" destid="TOP"/>
</element>
</site>
My understanding is that the submission parameters (with defaults
for when
they're not supplied) will represent the structure of my reports.
There are
no actual forms for a user to type into.
I have been using the friends database example to work from as it
seems to
most closely resemble what I'm trying to do. My questions:
* Am I on the right track here?
* How, if this looks right, do I pick up my GET parameters through
the RIFE
framework when there hasn't been a form to submit them, and how to
construct
the URLs to succeeding pages without hard coding stuff like /stats
etc.
* The templates are very complicated and hence the display Java
code will be
too (lots of nested blocks). It looks to me as if I have to have a
lot of
different mini classes of the DisplayRowProcessor type scattered
around.
Sorry this is so rambling, but I hope someone can advise me before
I go too
far down a potential blind alley!
Thanks,
David Herbert.
_______________________________________________
Rife-users mailing list
[email protected]
http://www.uwyn.com/mailman/listinfo/rife-users
--
Geert Bevin Uwyn bvba
"Use what you need" Avenue de Scailmont 34
http://www.uwyn.com 7170 Manage, Belgium
gbevin[remove] at uwyn dot com Tel +32 64 84 80 03
PGP Fingerprint : 4E21 6399 CD9E A384 6619 719A C8F4 D40D 309F D6A9
Public PGP key : available at servers pgp.mit.edu, wwwkeys.pgp.net
_______________________________________________
Rife-users mailing list
[email protected]
http://www.uwyn.com/mailman/listinfo/rife-users
