Jason Hines | 1 Jan 09:51 2004

NDF namespace modularity in code


Would it be possible to have Node accept an arbitrary set of attributes 
on the node:definition tag, and it be accessable in the php array with 
the others?

For example:

<node:definition foo="bar" hello:world="bleh" path="..." />

Seen as:

'path' => '...',
'foo' => 'bar',
'hello:world' => 'bleh'

This sorta breaks the strict DTD, so there is a good argument for not 
providing such freedom.  Was curious on others' thoughts, for I can see 
this being infinitely useful as well.  (fast development for apps that 
use their own namespaces in node, without special XSLT work required for 
each app)

jason
Jean-Christophe Michel | 1 Jan 11:21 2004

Re: NDF namespace modularity in code

Le jeu 01/01/2004 à 09:51, Jason Hines a écrit :
> Would it be possible to have Node accept an arbitrary set of attributes 
> on the node:definition tag, and it be accessable in the php array with 
> the others?
> 
> For example:
> 
> <node:definition foo="bar" hello:world="bleh" path="..." />
> 
> Seen as:
> 
> 'path' => '...',
> 'foo' => 'bar',
> 'hello:world' => 'bleh'

Try it, but i think it should work; it would respect node's DTD if you
use your own namespace: 

<node:definition myapp:foo="bar" ...>

You simply need to define a DTD, but maybe xsltproc doesn't complain too
much without...
--

-- 
Jean-Christophe Michel <jc.michel@...>
Symétrie
mark benedetto king | 1 Jan 17:30 2004

Re: svn commit: r8131 - trunk/doc/book/book

On Wed, Dec 31, 2003 at 06:11:08PM -0600, sussman@... wrote:
> +        <command>inetd</command>.  The IANA has reserved TCP port 3690
> +        for the svnserve protocol, so on a Unix-like system you can
> +        add a line to <literal>/etc/services</literal> like
> +        this:</para>

I belive it should be called "the Subversion protocol", or perhaps
"Subversion's native protocol".

Also, One Day Soon you might not have to actually add that line, since
OS vendors will probably scramble to be the first ones on their block
to get it into their shipped /etc/services.  You might want to say
"add (if it doesn't already exist)".

--ben
Manuel Holtgrewe | 1 Jan 20:21 2004

Namespace of param

Hi

We use the <param> tag in more than one environments:

    * parameters for nodes/templates
    * parameters for form validators/filters

For xsl to work correctly, we would have to use param explicitely as
node:param since the transformation code is in the node2ary.xsl...

I do not think this very clean, though. What about introducing a
"common" namespace:

    <node:definition>
        <form:validator>
            <bc:param></bc:param>
        </form:validator>
    </node:definition>

Thoughts?

Manuel

--

-- 
Unix definitely is a user friendly operating system.
- It is only picky with its friends.
Jean-Christophe Michel | 1 Jan 20:37 2004

Re: Namespace of param

Le jeu 01/01/2004 à 20:21, Manuel Holtgrewe a écrit :
> Hi
> 
> We use the <param> tag in more than one environments:
> 
>     * parameters for nodes/templates
>     * parameters for form validators/filters
> 
> For xsl to work correctly, we would have to use param explicitely as
> node:param since the transformation code is in the node2ary.xsl...
> 
> I do not think this very clean, though. What about introducing a
> "common" namespace:
> 
>     <node:definition>
>         <form:validator>
>             <bc:param></bc:param>
>         </form:validator>
>     </node:definition>
> 
> Thoughts?

You can test for localname() only, so in form:validators you would
use/validate form:param, and in your ndf2php.xsl you would match params
with

<xsl:template match="*">
  <xsl:if test="localname() = 'param'">
    ...

(Continue reading)

Jason Hines | 1 Jan 21:45 2004

Re: Namespace of param


I think of the node namespace as being the _common_ namespace.  (it is 
the NDF afterall)

<form:validator>
   <node:param></node:param>
</form:validators>

Is that confusing?  I'm not sure. =]

jason

Manuel Holtgrewe wrote:
> Hi
> 
> We use the <param> tag in more than one environments:
> 
>     * parameters for nodes/templates
>     * parameters for form validators/filters
> 
> For xsl to work correctly, we would have to use param explicitely as
> node:param since the transformation code is in the node2ary.xsl...
> 
> I do not think this very clean, though. What about introducing a
> "common" namespace:
> 
>     <node:definition>
>         <form:validator>
>             <bc:param></bc:param>
>         </form:validator>
(Continue reading)

Jason Hines | 2 Jan 09:36 2004

resource.php issue


i've been experimenting with a few alternate way to use Resource within 
the aspect of a top node.

1. Resource extends Node, gets automatically added as child by Node if 
resources are found.
2. Resource uses node/tpl/Resources.tpl with arrays $css_resources and 
$js_resources, and Node calls $Resource->ApplyTemplate($this)
3. some others..

However I've also tried working with the current implementation of 
Resource::GetInstance().  The problem here is that the Top app is 
rendered by Node before the children.. So the children are setting their 
resources _after_ the Top app sets tpl vars for them.

hmmm

jason
Jean-Christophe Michel | 2 Jan 11:07 2004

Re: resource.php issue

Le ven 02/01/2004 à 09:36, Jason Hines a écrit :
> i've been experimenting with a few alternate way to use Resource within 
> the aspect of a top node.
> 
> 1. Resource extends Node, gets automatically added as child by Node if 
> resources are found.
> 2. Resource uses node/tpl/Resources.tpl with arrays $css_resources and 
> $js_resources, and Node calls $Resource->ApplyTemplate($this)
> 3. some others..
> 
> However I've also tried working with the current implementation of 
> Resource::GetInstance().  The problem here is that the Top app is 
> rendered by Node before the children.. So the children are setting their 
> resources _after_ the Top app sets tpl vars for them.

If they set their tplvars in main()...
You can override Main() and call _RunChildren before _FetchTempalte if
you want to, but in this case we loose the cache handling made in
Node::Main() :(

--

-- 
Jean-Christophe Michel <jc.michel@...>
Symétrie
Jean-Christophe Michel | 3 Jan 01:01 2004

fileupload

Jason,

Rethinking to FileUpload and the copy_to param,
i think it's not a good idea to do this.
In most cases the action 'copy_to' must be done only if the form
validates, not in all cases. So having it done automatically is not
wise.
Maybe the input class can provide the api to do it simply, but not more
imo.
--

-- 
Jean-Christophe Michel <jc.michel@...>
Symétrie
Jean-Christophe Michel | 3 Jan 01:02 2004

bootstrap

in bootstrap/build.xml there seems to miss the target resources;
the ndf target doesn't have the right xsl sucession (see in
testsite/build.xml)
and qry target doesn't need translation imho.
--

-- 
Jean-Christophe Michel <jc.michel@...>
Symétrie

Gmane