On Mon, 2005-11-21 at 13:41, Dan Baker wrote:
> "Robert Cummings" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > Here is an example of a layout template:
> >
> > -----------------------------------------------------------------------------
> > <jinn:prepend/>
> > <html>
> >
> > <head>
> > <title><jinn:pageTitle/></title>
> >
> > <style type="text/css">
> > <!--
> > <jinn:template path="css/main.template"/>
> > -->
> > </style>
> >
> > <jinn:accumulatorFlush name="javaScriptTags"/>
> > <jinn:accumulatorFlush name="javaScriptTags" dynamic="true"/>
> >
> > // -->
> > </script>
> >
> > </head>
>
> I'm curious ... how do you generally handle forms and urls? What if the
> programmer wants to add a link, something like:
> <a href="page.php?op=View&id=1234">View my info</a>
>
> How is the data (op=View&id=1234) separated from the formatting?
There are two ways for retrieving data. The first you have seen is the
tag form, but obviously that's a problem when the data goes into a tag
:) For this there is the embed form (a simple example follows but data
can be retrieved from modules/components in the same way):
<a href="page.php?op=View&id={jinn:echo value={jinn:getValue name=_GET,
path=id}}">
Embeds can be nested as can tags. Additionally, embeds can be used
outside of tags, they're just most convenient there.
With respect to forms, InterJinn supplies a form engine that does most
of the rendering, and which can be assigned to slices. Then output is as
simple as:
<jinn:render name="someModule" selector="formOpen">
<jinn:render name="someModule" selector="country_field"/>
<jinn:render name="someModule" selector="formClose">
Or if you want to customize the form field but still have the internal
validation semantics:
<jinn:render name="someModule" selector="formOpen"/>
<input type="text" name="country" value="{jinn:echo value={jinn:getValue
...}} size="20" />
<jinn:render name="someModule" selector="formClose"/>
As long as you use the internal form open and close semantics, and use
the same name given to the field internally, you can render the field as
you would in HTML. I generally don't use that method, since I like to
use configuration arrays or properties to determine how the fields look.
Either way, the engine is very flexible and gives the developer lots of
choice in how they go about the display and how much control they give
the designer.
Unfortunately the documentation for the form engine isn't currently up
to date, since I've added less cumbersome techniques for creating forms
than what it currently documents. The faster techniques don't require
working with the objects but rather just define configuration arrays
that then generate everything else.
Let me know if you have any other questions.
Cheers,
Rob.
--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
