handling components

If I have a seaside component and want to make it a page in pier, how do
I do that?  What if I want to make it a part of a page?

I have a feeling the pier way is much different.  Judging by how
PRDistribution sets things up, it looks as if components are wrapped in
PRComponent and have a component class.  But I've been unable to see
where actual rendering happens, or where state goes.

The concrete problem motivating these questions is that I want to
display a list of files whose name match a certain pattern in a certain
directory.  The pattern and the directory could be hardcoded, but it
would be more interesting if they were editable in the web.

This will display a list of the files; if you click on one of them you
will see it.  That sounds like a job for PRFile, though again I'm not
exactly sure how that gets hooked in.

This is all likely to get more complex as I extract relations between
files, parse the contents of the files and show information based on the
parse.  But for now I'm just working on the "simple" stuff.

Any hints?
Thanks.
Ross

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

> If I have a seaside component and want to make it a page in pier, how do
> I do that?

Add > Select "Component" > Select "Component Class"

> What if I want to make it a part of a page?

You embed it into the page with an embed-link:

    A Seaside component: +/path/to/my/component+

> I have a feeling the pier way is much different.  Judging by how
> PRDistribution sets things up, it looks as if components are wrapped in
> PRComponent and have a component class.  But I've been unable to see
> where actual rendering happens, or where state goes.

PRDistribution creates an initial model from a script. Doing it from
the web goes through a series of command objects, but in the end you
have the same model. State is stored in the components and rendering
happens in #renderContentsOn: of the components, just as in default
Seaside.

> The concrete problem motivating these questions is that I want to
> display a list of files whose name match a certain pattern in a certain
> directory.  The pattern and the directory could be hardcoded, but it
> would be more interesting if they were editable in the web.

You can do this with something like this:

    +value:children|link|target=/path/to/directory|select=File+

> This is all likely to get more complex as I extract relations between
> files, parse the contents of the files and show information based on the
> parse.  But for now I'm just working on the "simple" stuff.

For this requirement you presumably require to add some code of you own.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

On Fri, 2009-09-25 at 07:44 +0200, Lukas Renggli wrote:
> > If I have a seaside component and want to make it a page in pier, how do
> > I do that?
>
> Add > Select "Component" > Select "Component Class"
Is there some registration process to get items to appear on that list?
I tried adding users; that seemed to reuse the existing user list.  At
the same time, I didn't see a direct way to add a user; that is, I had
to add the list, and then hit the add button of the list.
>
> > What if I want to make it a part of a page?
>
> You embed it into the page with an embed-link:
>
>     A Seaside component: +/path/to/my/component+
Does this assume step 1, so that my/component is a page (class
PRComponent) setup with an instance of my component? More precisely, I think the Magritte way is different.  I think I could
subclass PRObject to create a class with instance vars dir and pattern.
On the class side implement descriptionDir and descriptionPattern (which
maybe would create the accessors if I hadn't bothered?).
But then I don't know how to hook that up so one can create an instance
through the web.
And I don't know how to change the default display (the default edit
view is probably fine) so it shows, e.g., the list of files in dir
matching pattern.

When you referred to things being addressable through the web, in
response to my earlier question about security, I had assumed that the
components of a page were not addressable.  I see now that most
components, if included through +path/component+, are addressable (and
presumably can be viewed separately if one is so inclined).
>
> > The concrete problem motivating these questions is that I want to
> > display a list of files whose name match a certain pattern in a certain
> > directory.  The pattern and the directory could be hardcoded, but it
> > would be more interesting if they were editable in the web.
>
> You can do this with something like this:
>
>     +value:children|link|target=/path/to/directory|select=File+
Let's see if I understand.
Do parameters like |foo=bar get translated into method calls foo: "bar"?
And |foo=bar|with=blah becomes sends of foo: "bar" and then with:
"blah", rather than foo: "bar" with: "blah"?
These are directed to my component, not the children?  But the thing
with  +value:children...+ is a PRPage, not my component, so that won't
work.  So maybe my component should subclass PRPage?
So I create a component that implements setters for target: and select:.
When it receives select: (if I can count on the order) it clears it's
existing list of children and repopulates it with appropriate PRFile's.
And then the value:children|link will display them.
?
>
> > This is all likely to get more complex as I extract relations between
> > files, parse the contents of the files and show information based on the
> > parse.  But for now I'm just working on the "simple" stuff.
>
> For this requirement you presumably require to add some code of you own.
Well, I already added some code, so maybe I don't understand.
The files in the directory may change (both the names of the files and
the contents), and so I can't use a static list.

Thanks for all your help.
Ross


_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

>> Add > Select "Type" > Select "Component Class"
> Is there some registration process to get items to appear on that list?

Type: all PRStructure subclasses that are not abstract
Component Class: all PRWidget classes that are not abstract, all
Seaside root components

> I tried adding users; that seemed to reuse the existing user list.  At
> the same time, I didn't see a direct way to add a user; that is, I had
> to add the list, and then hit the add button of the list.

I do not understand.

> When you referred to things being addressable through the web, in
> response to my earlier question about security, I had assumed that the
> components of a page were not addressable.  I see now that most
> components, if included through +path/component+, are addressable (and
> presumably can be viewed separately if one is so inclined).

Yes, if you have the permissions you can individually navigate to the
components, given that there is a link or that you know the URL.
Typically components are not linked directly though, but embedded into
some other page.

No method calls. Value links (PRValueLink) are just a special kind of
link that embeds some dynamically created content, similar to a
component but without state. See the documentation at
<http://bit.ly/294VHv>.

> These are directed to my component, not the children?  But the thing
> with  +value:children...+ is a PRPage, not my component, so that won't
> work.  So maybe my component should subclass PRPage?

PRPage is a model object.
WAComponent is a view object.

See <http://www.piercms.com/doc> for details.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

On Fri, 2009-09-25 at 18:22 +0200, Lukas Renggli wrote:
>
> > I tried adding users; that seemed to reuse the existing user list.
>  At
> > the same time, I didn't see a direct way to add a user; that is, I
> had
> > to add the list, and then hit the add button of the list.
>
> I do not understand.

>From a web interface point of view, I thought there would be a way to
add a new user directly.  As far as I can tell, there isn't.

It seems one must first create a Pier Users component, and then work
within it.

I was a little surprised the Pier Users component seemed to use the
existing users list, rather than create a new one.

>From a development point of view, I was a little puzzled.  I can see
there is a PUUser object, which class side description* methods.  I
think that means it's setup for Magritte.  So I thought that might be
sufficient to make it possible to create one from the web.

Also, I'm confused about the roles of components and models.
I see now that there is a PUUsersWidget; I think this is what I added.
It does not hold a user list, but references it with

members
        ^ self context kernel users

I think what this means is that I could produce a quick and dirty widget
that was also a model (holds directory and pattern for files, knows how
to figure out which files are relevant), or I could have an explicit
Magritte object with the model.  But then do I need another widget to
display the magritte object, e.g., for editing the instance variables?

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

> >From a web interface point of view, I thought there would be a way to
> add a new user directly.  As far as I can tell, there isn't.
>
> It seems one must first create a Pier Users component, and then work
> within it.

Yes, there are several components to edit users, to edit groups, to
change various settings, to import/export the site, to observe the
server state, to search for broken links, etc.

> I was a little surprised the Pier Users component seemed to use the
> existing users list, rather than create a new one.

Why would they create a new one?

Pier-Security models a unix-like security system, there is a single
global list of users/groups stored in the kernel (root).

The ACL based security package could define users/groups locally, by
adding user/group structures.

> I think what this means is that I could produce a quick and dirty widget
> that was also a model (holds directory and pattern for files, knows how
> to figure out which files are relevant), or I could have an explicit
> Magritte object with the model.  But then do I need another widget to
> display the magritte object, e.g., for editing the instance variables?

You can embed any Seaside component into Pier. It does not need to use Magritte.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

On Fri, 2009-09-25 at 18:22 +0200, Lukas Renggli wrote: Yes, I saw that.  But I don't understand what happens with the
parameters.  Are you saying the +value...+ above will work without any
new code on my part?  Somehow I have to create the children to iterate
over, don't I?
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki