Posted by Robert Cummings on 11/22/05 02:52

On Mon, 2005-11-21 at 18:46, Dan Baker wrote:
> "Robert Cummings" <robert@interjinn.com> wrote in message
> news:1132600810.27185.32.camel@blobule.suds...
> > On Mon, 2005-11-21 at 13:41, Dan Baker wrote:
> >> 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}}">
>
> It appears that the data "op=View" is embedded in the html data. This seems
> strange, because the PHP programmer is the one who needs to set this value,
> not the page designer.

You asked for a sample of how to do dynamic link parameters. Dynamic
parameters can come from many sources (_GET, _POST, component, foreach,
etc). I gave you an example of one parameter being dynamic, the first I
left as static since perhaps the page itself determines the value.
InterJinn's TemplateJinn employes a data "pull" philosophy. Component
developers make available data and templates consume it (reverse of
smart which forces developers to import templates and populate the
template). Generally for simplicity I just set member vars on the
component object. But vars can be set anywhere depending on what is
agreed upon by the developer and the designer. The render tag bypasses
lower level data retrieval and just requests a chunk of output by
selector name.

> Also, the jinn:getValue seems a lot like programming -- The "id" value must
> come from a database, based on who is currently logged in. I assume it can
> be done, but seems like these queries would get rather complex, as well as
> redundant.

Decisions are made in any design. Since InterJinn employs data pull
mechanisms, and modules/components are created to be consumed by
templates, such that designers can import any module they want (and as
many) and just layout the data how they please, it was imperative that
one module's data not stomp on another module's data. In this way the
{getValue} embed drills down into the data structures of an existing
array or object. is this programming? Not really, it's no more
programming than you opening up a dictionary, jumping to the A section,
and then looking for Apple. This is data retrieval.

> Seems like you are changing from programming in PHP to
> programming in this new jinn language.

TemplateJinn employes very few logic techniques. Business logic is
expected to occur in the modules/components/compilers. I guess in the
above example I could have used the following instead:

<a href="page.php?op=View&id={jinn:render name=someModule, path=id}">

But this presumes the id comes from a module. I just showed an example
of retrieving the ID from the GET parameters to the current page
*shrug*. Also, it is true that TemplateJinn introduces new syntax, I
never said it didn't, but I am happy to pay the small price of some new
syntax to increase the readability and brevity of my templates.

> The "id" value must come from a database, based on who is
> currently logged in.

As pointed out in a previous post, a developer can wrap such low level
data requests in custom tags. if I want cross site template access to
the currently logged in user's ID then I'd add a custom tag to do the
following:

<a href="page.php?op=View&id={project:user field=id}">

> I am interested in how this works, but am skeptical.

No problem, the "programming in X template" instead of "programming in
PHP" objection is raised often. I've given previous arguments about the
merits of templates and concise data retrieval, display logic versus
business logic, and meta tags versus traditional tags. Everything done
in TemplateJinn can be done in PHP, absolutely since templates compile
to PHP pages, but templates provide a layer between the soup of PHP
necessary to accomplish that, and the designer. Even as a developer I
don't want to engage in the soup necessary to accomplish everything
TemplateJinn now does for me -- unfortunately I maintain some sites that
do employ the soup system.

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. |
`------------------------------------------------------------'

[Back to original message]