Daniel <[EMAIL PROTECTED]> writes:
>Hi,
>Generally, I think the flow of execution is as follows (I'm sure it's
>documented somewhere but I don't have the link), and please correct if
>this is wrong.
>Here goes:
>Given a URL, Turbine parses it to determine:
>1. action (with event)
>2. screen
page, folks, page. It then calulates from the page name
(e.g. demo,Foo.vm) in various stages:
- The page class to use. VelocityPage most of the time
- The screen class to use. VelocityScreen or your own screen
- The layout class to use. VelocityOnlyLayout probably
- The screen template to use. Gets mapped from the page name by the
Velocity Service. Ends up e.g. as .../templates/screens/demo/Foo.vm
- The layout template to use. Might end up as ../template/layouts/Default.vm
if you don't use multiple layout templates.
Then Turbine runs the Page _class_, which in turn runs the Layout
class, which runs the screen class which evaluates the Screen
template; the layout class puts the result of the scren in the context
for the Layout template, runs it and returns the result to the user.
And don't confuse the screen with the page. ;-)
Regards
Henning
>3. name/value pairs as request parameters
>If there is an action, then it its code gets executed either via a default
>doPerform(..) or doYourMethod(..).
>Next comes the "renderable screen", which Turbine/Velocity would locate
>template .vm files (if applicable) for and merges them into the various
>page components (Page, Layout, Screen, Navigation, etc.), including the code
>from your corresponding screen class.
>Regards,
>Daniel
>On Thu, 8 Jul 2004, Jeffery Painter wrote:
>>
>> sounds correct to me...
>>
>> On Thu, 8 Jul 2004, Ryan Gantt wrote:
>>
>> > So the execution DOES go straight to the action class, and you have to
>> > manually provide the calls to the Intake service, etc?
>> >
>> > If I'm reading this correctly, there is *no* middle man class between
>> > the form submission and the call to the action class. Is that correct?
>>
>>
>> --
>> Jeffery Painter
>> President
>> Kiasoft, Inc. (910) 352-3699
>> 3205 Randall Parkway, Suite 119
>> Wilmington, NC 28403
>>
>> - --
>> [EMAIL PROTECTED] http://kiasoft.com
>> PGP FP: 9CE8 83A2 33FA 32B1 0AB1 4E62 E4CB E4DA 5913 EFBC
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.2.1 (GNU/Linux)
>>
>> iD8DBQE/qEQE5Mvk2lkT77wRAnMJAJ9vJ6qOkg/mvqqIpz7troCEQJ8bFACglu/U
>> YNXabx7DZOV2Hd9LwSTmGpY=
>> =dWiu
>> -----END PGP SIGNATURE-----
>>
>> ---------------------------------------------------------------------
>> 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]
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
"Fighting for one's political stand is an honorable action, but re-
fusing to acknowledge that there might be weaknesses in one's
position - in order to identify them so that they can be remedied -
is a large enough problem with the Open Source movement that it
deserves to be on this list of the top five problems."
-- Michelle Levesque, "Fundamental Issues with
Open Source Software Development"
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
