headers
Jason Hines | 1 Jan 2004 09:51

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
Permalink | Reply | 1 comment |
headers
Jean-Christophe Michel | 1 Jan 2004 11:21
Favicon

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
Permalink | Reply | 0 comments |
headers
mark benedetto king | 1 Jan 2004 17:30

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
Permalink | Reply | 0 comments |
headers
Manuel Holtgrewe | 1 Jan 2004 20:21

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.
Permalink | Reply | 2 comments |
headers
Jean-Christophe Michel | 1 Jan 2004 20:37
Favicon

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)

Permalink | Reply | 0 comments |
headers
Jason Hines | 1 Jan 2004 21:45

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)

Permalink | Reply | 0 comments |
headers
Jason Hines | 2 Jan 2004 09:36

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
Permalink | Reply | 1 comment |
headers
Jean-Christophe Michel | 2 Jan 2004 11:07
Favicon

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
Permalink | Reply | 0 comments |
headers
Jean-Christophe Michel | 3 Jan 2004 01:01
Favicon

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
Permalink | Reply | 2 comments |
headers
Jean-Christophe Michel | 3 Jan 2004 01:02
Favicon

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
Permalink | Reply | 0 comments |

Gmane