Nabble - SmallWiki

Re: Some issues on FireFox

2009-10-04T21:42:10Z

I cannot reproduce any of this with FireFox 3.5.3 on Mac. Do you maybe
have cookies disabled. Are you using some special plugins?

Yes, I use many. Switching them off and on found that Cooliris is the offender. Thank you for the idea, I've just already forgot there are plugins in FF :)

--
Dennis Schetinin

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

Re: Some issues on FireFox

2009-10-04T14:44:09Z

I cannot reproduce any of this with FireFox 3.5.3 on Mac. Do you maybe
have cookies disabled. Are you using some special plugins?

Lukas

2009/10/4 Dennis Schetinin <chaetal@...>:

> I (still) observe a strange behaviour of Pier on FireFox 3.5.3. I'd
> summarize that as following: (some?) actions are just 'ignored' on the main
> page but are ok at 'About' page. For example: clicking login - entering the
> username and password - (regardless of correct or incorrect) getting back to
> the page without any changes (neither logged-in nor error messages). Being
> logged-in (from 'About' and then back to root) pressing '+' in Pier commands
> is also ignored. Same for clicks on 'Configure', 'Toggle Halos', 'Profiler',
> 'Memory' at the bottom of the page...
>
> With Chrome everything seems to be correct...
>
> This is actual for Pharo (pharo1.0-10451-BETAweb09.09.3, and
> pharo1.0-10466-BETAweb09.10.1) and 'original' (Squeak) Pier (Pier-1.2.app).
>
> --
> Dennis Schetinin
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>

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

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

Some issues on FireFox

2009-10-04T10:18:22Z

I (still) observe a strange behaviour of Pier on FireFox 3.5.3. I'd summarize that as following: (some?) actions are just 'ignored' on the main page but are ok at 'About' page. For example: clicking login - entering the username and password - (regardless of correct or incorrect) getting back to the page without any changes (neither logged-in nor error messages). Being logged-in (from 'About' and then back to root) pressing '+' in Pier commands is also ignored. Same for clicks on 'Configure', 'Toggle Halos', 'Profiler', 'Memory' at the bottom of the page...

With Chrome everything seems to be correct...

This is actual for Pharo (pharo1.0-10451-BETAweb09.09.3, and pharo1.0-10466-BETAweb09.10.1) and 'original' (Squeak) Pier (Pier-1.2.app).

--
Dennis Schetinin

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

Re: Gracefully Degrading Lightbox from Command Column

2009-10-01T09:45:13Z

Ok well I'm not necessarily tied to lightbox, I just thought it would be cool. I've been playing with something like this instead.

renderCellLinkContent: aFoo on: html

    self commands
        do: [ :each |
            html submitButton
                onClick: 'confirm(''Are you sure you wish to remove', aFoo name,'?''); return false';
                callback: [ each key value: aFoo ];
                with: each value ]
        separatedBy: [ html space ]

The callback does the WAComponent confirm:.

So this degrades well, my only problem is, I don't know how to get the result of the js dialog it and call removeFoo: aFoo if it's true.

Joel

On Thu, Oct 1, 2009 at 12:17 PM, Lukas Renggli <renggli@...> wrote:

>> The point is that the light-box does not use Javascript (AJAX) to get
>> it displayed, so it will generate the HTML either way. JavaScript is
>> only used afterwards to get the dialog centered in the middle of the
>> page and have the background dimmed. I haven't seen a lightbox yet
>> that can do this cross-browser only using CSS.
>
> How would a lightbox get displayed without using js?
> You have to do something to get the lightbox to display,
> that something requires javascript to happen.

No. #lightbox: is like #call:. It does a full refresh to the server
and generates a completely new page with the background and lightbox
HTML. The only difference between #call: and #lightbox: is that call
does not render the parent component, #lightbox: does to make it shine
through using some CSS effects. You can easily observe that in
FireBug.

Now of course there are nicer ways to do a lightbox, e.g. by loading
the dialog using an AJAX call. However this does not work as part of a
flow and requires you to write and adapt some Javascript code to work
with your page layout.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

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

Re: Gracefully Degrading Lightbox from Command Column

2009-10-01T09:38:30Z

On Thu, Oct 1, 2009 at 12:17 PM, Lukas Renggli <renggli@...> wrote:

>> The point is that the light-box does not use Javascript (AJAX) to get
>> it displayed, so it will generate the HTML either way. JavaScript is
>> only used afterwards to get the dialog centered in the middle of the
>> page and have the background dimmed. I haven't seen a lightbox yet
>> that can do this cross-browser only using CSS.
>
> How would a lightbox get displayed without using js?
> You have to do something to get the lightbox to display,
> that something requires javascript to happen.

No. #lightbox: is like #call:. It does a full refresh to the server
and generates a completely new page with the background and lightbox
HTML. The only difference between #call: and #lightbox: is that call
does not render the parent component, #lightbox: does to make it shine
through using some CSS effects. You can easily observe that in
FireBug.

Now of course there are nicer ways to do a lightbox, e.g. by loading
the dialog using an AJAX call. However this does not work as part of a
flow and requires you to write and adapt some Javascript code to work
with your page layout.

ah, i understand.

thanks.

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

Re: Gracefully Degrading Lightbox from Command Column

2009-10-01T09:17:52Z

>> The point is that the light-box does not use Javascript (AJAX) to get
>> it displayed, so it will generate the HTML either way. JavaScript is
>> only used afterwards to get the dialog centered in the middle of the
>> page and have the background dimmed. I haven't seen a lightbox yet
>> that can do this cross-browser only using CSS.
>
> How would a lightbox get displayed without using js?
> You have to do something to get the lightbox to display,
> that something requires javascript to happen.

No. #lightbox: is like #call:. It does a full refresh to the server
and generates a completely new page with the background and lightbox
HTML. The only difference between #call: and #lightbox: is that call
does not render the parent component, #lightbox: does to make it shine
through using some CSS effects. You can easily observe that in
FireBug.

Now of course there are nicer ways to do a lightbox, e.g. by loading
the dialog using an AJAX call. However this does not work as part of a
flow and requires you to write and adapt some Javascript code to work
with your page layout.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Re: Gracefully Degrading Lightbox from Command Column

2009-10-01T08:53:51Z

On Thu, Oct 1, 2009 at 10:15 AM, Lukas Renggli <renggli@...> wrote:

The point is that the light-box does not use Javascript (AJAX) to get
it displayed, so it will generate the HTML either way. JavaScript is
only used afterwards to get the dialog centered in the middle of the
page and have the background dimmed. I haven't seen a lightbox yet
that can do this cross-browser only using CSS.

How would a lightbox get displayed without using js?

You have to do something to get the lightbox to display,

that something requires javascript to happen.

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

Re: Gracefully Degrading Lightbox from Command Column

2009-10-01T07:15:43Z

The point is that the light-box does not use Javascript (AJAX) to get
it displayed, so it will generate the HTML either way. JavaScript is
only used afterwards to get the dialog centered in the middle of the
page and have the background dimmed. I haven't seen a lightbox yet
that can do this cross-browser only using CSS.

> How I understand degradation is that you put in an onClick event what you
> want to happen, and return false. If javascript is disabled, it ignores the
> onClick and the element does what is in the callback.

Now for your problem I don't see an out of the box solution. If you
would implement your own lightbox that displays as an answer to an
#onClick: event, then you could have a standard fallback as you
describe. That approach does not work with the lightbox that comes
with Scriptaculous though, because it does a full-fresh and a normal
#call:.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Re: Gracefully Degrading Lightbox from Command Column

2009-10-01T06:55:06Z

How then do I set what I want to happen if javascript is disabled?

I create an MACommandColumn with this as the selector.

removeFooConfirm: aFoo

( self lightbox: (WAYesOrNoDialog new addMessage: 'Are you sure you wish to remove', aFoo name,'?'; yourself ))
ifTrue: [ self removeFoo: aFoo ]

I disable javascript in my browser. When I click "remove", I see in the html source that it's still trying to apply the light box, but since javascript is disabled, all I see is that the same page without a vertical scrollbar.

How I understand degradation is that you put in an onClick event what you want to happen, and return false. If javascript is disabled, it ignores the onClick and the element does what is in the callback.

On Thu, Oct 1, 2009 at 7:41 AM, Lukas Renggli <renggli@...> wrote:

> In a Magritte report, I have a "remove" command column. What I want is a
> confirmation lightbox that degrades to a normal seaside confirmation (
> separate page ) if javascript is disabled.

The default lightbox that comes with Scriptaculous does not use AJAX,
so it is degraded by default anyway ;-)

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

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

Re: Gracefully Degrading Lightbox from Command Column

2009-10-01T04:41:37Z

> In a Magritte report, I have a "remove" command column. What I want is a
> confirmation lightbox that degrades to a normal seaside confirmation (
> separate page ) if javascript is disabled.

The default lightbox that comes with Scriptaculous does not use AJAX,
so it is degraded by default anyway ;-)

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Gracefully Degrading Lightbox from Command Column

2009-10-01T04:09:19Z

In a Magritte report, I have a "remove" command column. What I want is a confirmation lightbox that degrades to a normal seaside confirmation ( separate page ) if javascript is disabled.

In my command column's renderCellLinkContent:on: method, it's no problem to call the seaside confirm from the callback, but I can't figure out how to call the lightbox from the onClick event.

I'm in GLASS so I've got scriptaculous to work with.

Thanks,

Joel

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

Re: Conditional visibility

2009-09-29T10:41:35Z

addendum:

The Magritte-Scriptaculous package also defines a third accessor to
all objects.

in addition to readUsing: and write:Using: there is added update:Using.

This allows the changing component (e.g. MASelectListComponentSU to
apply any changes to a different selector, so that the model can
respond dynamically to the change.

E.g.

description010CustomerName

^ MAStringDescription new
accessor: (#customerName asAccessor update: #customerNameChangedTo;
options: #customerNamesAvailable);
label: 'Customer Name';
fieldSize: 30;
propertyAt: #filter put: #matchLeft;
componentClass: MAAutoCompletingTextInputComponent;
beSearchable;
bePersisted;
yourself

best regards

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

Re: Pier for Seaside 3.0 plans

2009-09-28T23:52:33Z

>> ... are there any?
>>
>> As there are plans of porting (recent) Pier to VW,
>
> who wants to do that?

It's in Cincom, AFAIK. I'm not yet sure it's ok to discuss details,
and anyway I don't know much...

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

Re: Conditional visibility

2009-09-28T17:55:31Z

erratum

copyForRealMemento

postCopyForRealMemento

super postCopyForRealMemento.

shipping := shipping copyForRealMemento.
billing := billing copyForRealMemento.
personal syncPersonalWithBilling: billing

Keith

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

Re: Conditional visibility

2009-09-28T17:45:40Z

On 28 Sep 2009, at 09:43, Lukas Renggli wrote:

>> I am still using lr.251 and asking the following questions to the
>> list.
>> 1) Is there a response to my requirement in more recent Magritte
>> versions?
>
> No.
>
>> 2) Has this topic already been covered in this list?
>
> Yes, also see the first question on
> <http://www.lukas-renggli.ch/smalltalk/magritte/faq>.
>
> Lukas
>

The magritte-scriptaculous package does what you want dynamically.

This defines additional properties on the accessor as in the following
example.

descriptionLicenceForCA
^MAStringDescription new
accessor: (#licenceForCA asAccessor visible: #isInCalifornia);
label: 'Licence # (California)';
addCondition: [ :v | v size between: 5 and: 10 ] labelled: 'Please
enter licence number';
priority: 80;
bePersisted;
beRequired;
beEditable;
yourself

The sub-accessors are stored as properties of the main accessor.
Additional sub-accessors available are:

#tooltip:
#readonly:
#visible:
#options: (dynamically compiled lists for select lists)
#cssClasses:

Mementos
========

Since the additional accessors refer to methods on the real model
object you cant use the conventional mementos because they hold the
state of the form in a dictionary and this has none of the behaviour
of a real object. To solve this there is an alternative Magritte-
RealMemento package which supplies almost equivalent mementos which
use copies of the actual model object to store the cached state.

e.g. MARealCheckedMemento etc.

The main difference being that only one cache of the whole object
structure is kept in the MARealCheckedMemento, related objects (sub-
forms aka internal/external edited objects) must use an MAStraitMemento.

A little care has to be taken to make the mementos work with sub-form
objects. The #copyForMemento method is available for any fine tuning
of the memento creation process. For example related objects need to
be copied, and any internal structure within the object needs to be
consistent. In the example bellow the related objects are explicitly
copied, and the internal relationship between the personal, and
billing object is re-established between the copies.

E.g.

copyForRealMemento

super copyForRealMemento.
shipping := shipping copyForRealMemento.
billing := billing copyForRealMemento.
personal syncPersonalWithBilling: billing

Components
==========

descriptionState

^ super descriptionState
beRequired;
componentClass: MASelectListComponentSU;
yourself

MASelectListComponentSU - differs from the standard SelectList in that
it triggers an scriptaculous update of the entire form, when the
selection is changed.

In this case, when the user selects the state of california in the
billing address sub-form, the "Licence for CA" field appears in the
personal data sub-form.

best regards

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

Re: Pier for Seaside 3.0 plans

2009-09-28T13:36:25Z

On Sep 28, 2009, at 4:13 PM, Dennis Schetinin wrote:

> ... are there any?
>
> As there are plans of porting (recent) Pier to VW,

who wants to do that?

> maybe it's better to port a newer version (if it exist in any form
> ofcourse)?
>
> --
> Dennis Schetinin
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki

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

Re: Pier for Seaside 3.0 plans

2009-09-28T07:35:16Z

> ... are there any?

Julian is currently working on integrating Pier with Seaside 3.0.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Pier for Seaside 3.0 plans

2009-09-28T07:13:57Z

... are there any?

As there are plans of porting (recent) Pier to VW, maybe it's better to port a newer version (if it exist in any form ofcourse)?

--
Dennis Schetinin

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

RE: Conditional visibility

2009-09-28T04:43:40Z

Thanks Lukas, I already knew about that trick. But it only works when
the component is initially built, and I would need the component to
change its view as the model changes without creating a new component.

So it looks as if I will have to extend the framework somehow.

> -----Original Message-----
> From: smallwiki-bounces@...
> [mailto:smallwiki-bounces@...] On Behalf Of Lukas Renggli
> Sent: lundi, 28. septembre 2009 10:44
> To: Magritte, Pier and Related Tools ...
> Subject: Re: Conditional visibility
>
> > I am still using lr.251 and asking the following questions
> to the list.
> > 1) Is there a response to my requirement in more recent
> Magritte versions?
>
> No.
>
> > 2) Has this topic already been covered in this list?
>
> Yes, also see the first question on
> <http://www.lukas-renggli.ch/smalltalk/magritte/faq>.
>
> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>

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

Re: Conditional visibility

2009-09-28T01:43:49Z

> I am still using lr.251 and asking the following questions to the list.
> 1) Is there a response to my requirement in more recent Magritte versions?

No.

> 2) Has this topic already been covered in this list?

Yes, also see the first question on
<http://www.lukas-renggli.ch/smalltalk/magritte/faq>.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Conditional visibility

2009-09-28T01:26:45Z

Conditional visibility

I have a requirement for a Magritte-generated Seaside component where the visibility of some of the model's property is dependent on the values of other properties. Something like this.

        descriptionMaidenName

                ^(MAStringDescription new)
                        selectorAccessor: 'maidenName';
                        label: 'Maiden name';
                        visible: [:aModel | aModel isVisibleInComponent];
                        yourself

I am still using lr.251 and asking the following questions to the list.
1) Is there a response to my requirement in more recent Magritte versions?
2) Has this topic already been covered in this list?

Thanks,
Michel.

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

Fwd: [Pharo-project] pharo1.0-10451-BETAweb09.09.3 in FireFox

2009-09-27T04:38:03Z

To Pier List

---------- Forwarded message ----------
From: Dennis Schetinin <chaetal@...>
Date: 2009/9/25
Subject: [Pharo-project] pharo1.0-10451-BETAweb09.09.3 in FireFox
To: pharo-project@...

I can't log in at the 'main' page (http://127.0.0.1:8080/seaside/pier)
in Pier. It just ignores all the inputs (both correct and incorrect)
simply redirecting from input form back to the main page. But from the
Blog or About page it works correctly. It's all using FireFox 3.5.3.
With Chrome it's ok everywhere, including 'main' page...

What can be the cause of the problem?

--
Dennis Schetinin

_______________________________________________
Pharo-project mailing list
Pharo-project@...
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Recaptcha as MAgritte component

2009-09-26T04:32:29Z

Hi,

On Wed, 2009-06-17 at 12:22 -0300, Sebastian Van Lacke wrote:

>> Hi, I need to generate some graphics dinamically for my application
>> and Gemstone doesn't provide draw classes.
>> Specifically I want to implement a Captcha validation in a form, with
>> a distorted text.
>>
>> How can I do it?
>>
> If you don't need to do it on your own you can use the recaptcha
> service (http://www.recaptcha.net). Fortunately I wrote a component
> for this last week. This is available at
>
> http://selfish.org/software/recaptcha

>
> It runs in Glass-dkh.231. If you have problems using it I'm happy
> to help out.
>
> Norbert

Now i use Recaptcha and it work well.

But i,m interesting to use it as Magritte  component ( only for simply use with other MADescription ) and i have do:

1) I copy the RSRecaptchaComponent to MARSRecaptchaComponent ( as subclass
of MAElementComponent ).

2) I create MARSRecaptchaComponentDescription with:
     defaultComponentClass -> MARSRecaptchaComponent
     kind -> RSRecaptcha

3) Now when rendering a component with a description based on
MARSRecaptchaComponentDescription :

        task call: ( collectionOfDescription asComponentOn: model )
                adValidateForm;
                addMessage: 'testo';
                yourself.

    The rendering work well ( i see MARSRecaptchaComponent right )

    But when test the hasValidateResponse with :

        validateSpecific: anObject
            super validateSpecific: anObject.
            anObject hasValidateResponse ifTrue:[ ] .

    the requestBody ( RSRecaptcha method ) go in error:

     The anRSRecaptcha   parameters dictionary have :
        'challenge' ->nil
        'response' -> nil.

I think registerCallbacksOn: html d'ont work well.

Thank for any consideration.

    Dario

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

Re: [Pharo-project] pharo1.0-10451-BETAweb09.09.3 in FireFox

2009-09-25T10:43:33Z

You should ask also in Pier mailing list. I cc to it.

2009/9/25 Dennis Schetinin <chaetal@...>

I can't log in at the 'main' page (http://127.0.0.1:8080/seaside/pier) in Pier. It just ignores all the inputs (both correct and incorrect) simply redirecting from input form back to the main page. But from the Blog or About page it works correctly. It's all using FireFox 3.5.3. With Chrome it's ok everywhere, including 'main' page...

What can be the cause of the problem?

--
Dennis Schetinin

_______________________________________________
Pharo-project mailing list
Pharo-project@...
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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

Re: handling components

2009-09-25T10:31:13Z

On Fri, 2009-09-25 at 18:22 +0200, Lukas Renggli wrote:

> >> > 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"?
>
> 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>.

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?

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

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

Re: handling components

2009-09-25T10:29:36Z

> >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

Re: handling components

2009-09-25T10:16:32Z

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

Re: handling components

2009-09-25T09:22:05Z

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

>> > 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"?

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

Re: handling components

2009-09-25T09:03:31Z

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?

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

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

Re: handling components

2009-09-24T22:44:31Z

> 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

Re: PRDistribution>>makePrivate:

2009-09-24T22:37:26Z

It doesn't look like #makePublic: is used at all. That's the default anyway.

Doru, can the method #makePublic: be removed?

Lukas

2009/9/25 Ross Boylan <ross@...>:
> This method seems to do the same thing as PRDistribution>>makePublic:.
> Am I missing some subtlety, or is this a bug?
>
> Ross
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

handling components

2009-09-24T21:48:30Z

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

PRDistribution>>makePrivate:

2009-09-24T21:38:03Z

This method seems to do the same thing as PRDistribution>>makePublic:.
Am I missing some subtlety, or is this a bug?

Ross

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

Re: Sub bulleted or ordered list

2009-09-24T06:07:01Z

On Thu, Sep 24, 2009 at 11:57 AM, Lukas Renggli <renggli@...> wrote:

http://www.piercms.com/doc/syntax#99639110

Does that help?

Yeah!!! Thanks! It worked. I used to have something like this:

-One bullet

-Two bullet

--a sub bullet of two bullet

That's doesn't work. You must do:

-One bullet

-Two bullet
--a sub bullet of two bullet

I removed a blank line between them!

Thanks.

Mariano

Lukas

2009/9/24 Mariano Martinez Peck <marianopeck@...>:

> Hi folks: I need something like the office bullet or ordered list, where you
> can have those lists and sublist. Those you use in Word using TAB key.
>
> I tried putting double -- or double ## but it doesn't work.
>
> Do you know how can I achieve that in Pier ?
>
> Best,
>
> Mariano
>

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

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

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

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

Re: Sub bulleted or ordered list

2009-09-24T05:57:26Z

http://www.piercms.com/doc/syntax#99639110

Does that help?

Lukas

2009/9/24 Mariano Martinez Peck <marianopeck@...>:

> Hi folks: I need something like the office bullet or ordered list, where you
> can have those lists and sublist. Those you use in Word using TAB key.
>
> I tried putting double -- or double ## but it doesn't work.
>
> Do you know how can I achieve that in Pier ?
>
> Best,
>
> Mariano
>
> _______________________________________________
> Magritte, Pier and Related Tools ...
> https://www.iam.unibe.ch/mailman/listinfo/smallwiki
>

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

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