a hash with explicit attributes (might be useful) for meta

1 view
Skip to first unread message

John Mettraux

unread,
Apr 18, 2007, 5:00:47 AM4/18/07
to pika...@googlegroups.com
Hi List,

o.meta["author"] = ...
o.meta.author = ...

would be thus accepted.


Cheers,

--
John Mettraux -///- http://jmettraux.openwfe.org

meta.rb

Nicolas Modrzyk

unread,
Apr 18, 2007, 10:19:15 AM4/18/07
to pika...@googlegroups.com
Sounds good.

Need to define what happens in the case the node has no meta associated to it.
-> raise exception (will be raised by Ruby if that is the case, but we should maybe wrap it?)
-> return nil

John Mettraux

unread,
Apr 18, 2007, 10:43:37 AM4/18/07
to pika...@googlegroups.com
2007/4/18, Nicolas Modrzyk <hell...@gmail.com>:

> Sounds good.
>
> Need to define what happens in the case the node has no meta associated to
> it.
> -> raise exception (will be raised by Ruby if that is the case, but we
> should maybe wrap it?)
> -> return nil

node.meta.author => nil
or
node.meta => exception

for now we could state that the Pikas grant an empty meta hash...


About Pikas and Connectors, I think that they are the same thing.

The BasePika could be inherited by all Pika and it would contain the
default [cascading] behaviours. The BasePika could be the HashPika.

Nodes could be whatever instance + meta.


楽しみ,

Nicolas Modrzyk

unread,
Apr 18, 2007, 10:53:25 AM4/18/07
to pika...@googlegroups.com
Looking at the jackrabbit metadata thing, and the way magnolia wraps metadata as custom nodes, I would put the metadata as an option.
So the base of all nodes has no metadata and just keeps its value (values ? in jcr, it is a list of values)

Completely agree on Pilkabase and Pikash.

"Nodes could be whatever instance + meta". what do you mean ? an instance of node right ?

Niko,


On 4/18/07, John Mettraux <jmet...@gmail.com> wrote:

John Mettraux

unread,
Apr 18, 2007, 6:47:11 PM4/18/07
to pika...@googlegroups.com
07/04/18 に Nicolas Modrzyk<hell...@gmail.com> さんは書きました:

> Looking at the jackrabbit metadata thing, and the way magnolia wraps
> metadata as custom nodes, I would put the metadata as an option.
> So the base of all nodes has no metadata and just keeps its value (values ?
> in jcr, it is a list of values)

OK for the optional meta, makes sense.

> Completely agree on Pilkabase and Pikash.
>
> "Nodes could be whatever instance + meta". what do you mean ? an instance of
> node right ?

Do you think we need a Node class ? Maybe in some cases. An array of
byte could be a Node, a String, an Integer,... Could we use a Hash as
a Node "a la" JCR ? And a list for "directory nodes" ?

Maybe my vocabulary is dead wrong, I should say :
leaf = whatever
non-leaf node = node type / directory (an extension of array ?)

wdyt ?

John

Nicolas H. Modrzyk

unread,
Apr 18, 2007, 8:07:03 PM4/18/07
to pika...@googlegroups.com
> Do you think we need a Node class ? Maybe in some cases. An array of
> byte could be a Node, a String, an Integer,... Could we use a Hash as
> a Node "a la" JCR ? And a list for "directory nodes" ?

Could we access the tree like Hapricot does ?
The thing is that I am not sure we know where the root is.

> Maybe my vocabulary is dead wrong, I should say :
> leaf = whatever
> non-leaf node = node type / directory (an extension of array ?)

there is no distinction between nodes and directory nodes (again, in
the rabbit).
A node is a leaf if list_children returns empty.

Maybe a good discussion would be to try to identify how a node is
defined in a flickr connector ?
How:
- access it
- copy,move,delete it (change the structure)
- change some of its metadata
- change its value
- query to find the node

A flickr node could be an image:
- with the different size resolutions
- with the comments and other metadata
or it could be something completely different.

Niko,

John Mettraux

unread,
Apr 18, 2007, 8:16:39 PM4/18/07
to pika...@googlegroups.com
2007/4/19, Nicolas H. Modrzyk <hell...@gmail.com>:

>
> > Do you think we need a Node class ? Maybe in some cases. An array of
> > byte could be a Node, a String, an Integer,... Could we use a Hash as
> > a Node "a la" JCR ? And a list for "directory nodes" ?
>
> Could we access the tree like Hapricot does ?
> The thing is that I am not sure we know where the root is.
>
> > Maybe my vocabulary is dead wrong, I should say :
> > leaf = whatever
> > non-leaf node = node type / directory (an extension of array ?)
> there is no distinction between nodes and directory nodes (again, in
> the rabbit).
> A node is a leaf if list_children returns empty.

You're right.

node.meta
node.children
?

> Maybe a good discussion would be to try to identify how a node is
> defined in a flickr connector ?

> How:
> - access it

n = pica.lookup(path)
puts n.meta.type # => "FlickRsomething"

> - copy,move,delete it (change the structure)

pica.cp x, y
pica.mv ...
pica.rm ...

> - change some of its metadata

n = pica.lookup path

n.meta.author = "toto"

n.save # or
pica.write / update / save n

> - change its value
> - query to find the node

nodes = pica.find do |n|
n.meta.type == "whatever"
end

> A flickr node could be an image:
> - with the different size resolutions
> - with the comments and other metadata
> or it could be something completely different.

Sounds cool.


楽し

Reply all
Reply to author
Forward
0 new messages