14 Apr
2006
14 Apr
'06
5:13 p.m.
Hi,
how can I disable the bottom line with "New Session", "Toggle Halo"
etc in pier ? The standard web user should not be able to make
dangerous things :-) Is that a matter of seaside itself ?
Regards and happy Easter !
Hans
14 Apr
14 Apr
5:22 p.m.
hi
it it the deployment mode of all seaside application
Hi,
how can I disable the bottom line with "New Session", "Toggle Halo"
etc in pier ? The standard web user should not be able to make
dangerous things :-) Is that a matter of seaside itself ?
so in the config page, go to configure (click) next to pier and set
deployment mode to false
Regards and happy Easter !
Thanks ;)
smae for all
Bye
Cédrick
5:24 p.m.
how can I disable the bottom line with "New
Session", "Toggle Halo"
etc in pier ? The standard web user should not be able to make
dangerous things :-) Is that a matter of seaside itself ?
Yes, go to /seaside/config, remove any unused applications and set
"deployment mode" of your pier application to true.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
5:33 p.m.
Hi,
works :-)
And how to prevent that everyone can call the ../seaside/config
page ? ;-) I think the removing the config is not the best :-)
(Ok, this are now very basic seaside questions....)
Regards
Hans
Am 14.04.2006 um 17:24 schrieb Lukas Renggli:
how can I
disable the bottom line with "New Session", "Toggle Halo"
etc in pier ? The standard web user should not be able to make
dangerous things :-) Is that a matter of seaside itself ?
Yes, go to /seaside/config, remove any unused applications and set
"deployment mode" of your pier application to true.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
5:46 p.m.
sorry for the last answer :-[ It was the opposite as Lukas said...
Hans N Beck a écrit :
Hi,
works :-)
And how to prevent that everyone can call the ../seaside/config
page ? ;-) I think the removing the config is not the best :-)
(Ok, this are now very basic seaside questions....)
actually config is protected by a password so it shouldn't be
accessible... ;)
if you want to change it evaluate WADispatcherEditor initialize
See you
Cédrick
6:24 p.m.
Hi
Am 14.04.2006 um 17:46 schrieb Cédrick Béler:
sorry for the last answer :-[ It was the opposite
as Lukas said...
don't worry, I've got the idea :-)
Hans N Beck a écrit :
hmm, I have loaded the Pier in a clean 3.8 image (and the Pier unix
security package), and there was no password needed to get the config
site...... is there any default login ?
Regards
Hans
Hi,
works :-)
And how to prevent that everyone can call the ../seaside/config
page ? ;-) I think the removing the config is not the best :-)
(Ok, this are now very basic seaside questions....)
actually config is protected by a password so it shouldn't be
accessible... ;)
if you want to change it evaluate WADispatcherEditor initialize
9:31 p.m.
Hi,
So now I've looked a little bit in the mailing archive, and I'm a
little bit confused:
It seems,
- that Seaside and Pier (or any other application in Seaside) can
have different security models. Both can handle its own user lists
and capabilities
- that there are 2 different security packages (unix inspired / ACL
based)
- both Seaside and Pier can add users (or user management in general)
only by typing something (what ?) in workspace
So if this is all true - what are the plans to make this all more
integrated, so that there is only one user management, and an
application may only extend the basic mechanism from seaside ? Or I'm
completly wrong here ?
Regards
Hans
Am 14.04.2006 um 18:37 schrieb Cédrick Béler:
hmm, I have loaded the Pier in a clean 3.8 image
(and the Pier unix
security package), and there was no password needed to get the config
site...... is there any default login ?
I think there is a default login when loading directly from the
pier package (that manages to load all depedencies) I dont really
remember but I think its login: admin pass: pier not sure at
all ;)
anyway, the best is probably to reset the pass by evaluating
WADispatcherEditor initialize
an interface will ask you for a user login and password that you'll
use for the page
http://localhost:XXXX/seaside/config
See you
Cédrick
_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki 
15 Apr
15 Apr
4:59 a.m.
New subject: Magritte
Has anyone done, or seen a sample of cascading dialog boxes done with only magritte
descriptions? Say I had a dropdown list of classes, and when one was selected, I want the
next drop down list to contain methods in that class, or maybe countries and states, or
whatever. How can the second MultipleOptionDescription get it's options: from the
selector on the instance that the first MultipleOptionDescription set the value on?
9:23 a.m.
New subject: Magritte
Has anyone done, or seen a sample of cascading dialog
boxes done
with only magritte descriptions? Say I had a dropdown list of
classes, and when one was selected, I want the next drop down list
to contain methods in that class, or maybe countries and states, or
whatever. How can the second MultipleOptionDescription get it's
options: from the selector on the instance that the first
MultipleOptionDescription set the value on?
Yes, however you need to specify the second description on the
instance-side to be able to define it according to the state of your
model. There are some examples on how to change descriptions on an
instance-bases in the slides of my Magritte Tutorial (Dynamic
Descriptions, 31-33) at <http://www.lukas-renggli.ch/smalltalk/
magritte>.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
9:58 a.m.
New subject: Magritte
I was just eating breakfast and wondering if it really makes sense to
define descriptions on the class-side. Sure this is a meta-thing, but
it is not something necessarily belonging to the class as we saw in
the mail of the original poster.
So it would probably make more sense to put descriptions describing
the instance to the instance-side, so that they can be easily created
depending on the current model state. The draw-back, there is usually
one, would be that retrieving the descriptions would be more
expensive as they cannot be cached anymore.
What do you think?
Lukas
On 15 Apr 2006, at 09:23, Lukas Renggli wrote:
--
Lukas Renggli
http://www.lukas-renggli.ch
Has anyone
done, or seen a sample of cascading dialog boxes done
with only magritte descriptions? Say I had a dropdown list of
classes, and when one was selected, I want the next drop down list
to contain methods in that class, or maybe countries and states, or
whatever. How can the second MultipleOptionDescription get it's
options: from the selector on the instance that the first
MultipleOptionDescription set the value on?
Yes, however you need to specify the second description on the
instance-side to be able to define it according to the state of your
model. There are some examples on how to change descriptions on an
instance-bases in the slides of my Magritte Tutorial (Dynamic
Descriptions, 31-33) at <http://www.lukas-renggli.ch/smalltalk/
magritte>.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki 
11:24 a.m.
New subject: Magritte
Lukas Renggli wrote:
I was just eating breakfast and wondering if it really
makes sense to
define descriptions on the class-side. Sure this is a meta-thing, but
it is not something necessarily belonging to the class as we saw in
the mail of the original poster.
So it would probably make more sense to put descriptions describing
the instance to the instance-side, so that they can be easily created
depending on the current model state. The draw-back, there is usually
one, would be that retrieving the descriptions would be more
expensive as they cannot be cached anymore.
What do you think?
Have you tried to remove caching from existing Magritte programs to test
if it is
really slower?
1:36 p.m.
New subject: Magritte
Have you tried to remove caching from existing
Magritte programs to
test if it is really slower?
Sure it is much slower, I profiled it when implementing the cache. I
just redid the test in the latest version and it shows that the cache
improves the description retrieval by a factor of 7000, of course
depending on the object hierarchy of the queried class. The reason it
is so slow is basically the use of #allSelector, that could be
improved (with more clever code or pragmas). Still I guess the factor
of 10^3 would stay the same.
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
5:03 p.m.
New subject: Magritte
...
The draw-back, there is usually one, would be that
retrieving
the descriptions would be more expensive as they cannot be
cached anymore.
Why it can be cached anymore? Can't just be posible to refactor the cache
subsystem to work instance based intead of class based?
I know that some systems allready have instance based caches. Some of them:
GOODS client by Avi Bryant,
rST,
OmniBase support
regards,
Sebsatian
PD: I'm not familiar with Magritte and recently interested in it because I
think it make archivable that an application could have a maintainable web
interface and desktop interface at a reasonably cost.
9 p.m.
New subject: Magritte
Have you tried
to remove caching from existing Magritte programs to
test if it is really slower?
Sure it is much slower, I profiled it when implementing the cache. I
just redid the test in the latest version and it shows that the cache
improves the description retrieval by a factor of 7000, of course
depending on the object hierarchy of the queried class. The reason it
is so slow is basically the use of #allSelector, that could be
improved (with more clever code or pragmas). Still I guess the factor
of 10^3 would stay the same.
Lukas
9:32 p.m.
New subject: Magritte
Lukas Renggli wrote:
Ok, doesn't seem to work, but let me explain what I'm doing. I'm
writing a component meant to be hosted in Pier, the component has
several settings it needs, and I was using class side descriptions to
provide the "settings" interface that Pier offers on any component.
However, looking at PRSettingsComponent, I see that it's not asking the
instance for it's description, it's asking the class directly, bypassing
any overrides I may have attempted on the instance side. Is that the
intention? Am I writing components wrong? Should I be subclassing
something in Pier rather than my own WAComponent subclass?
The Magritte tutorial is great btw, is there something similar for Pier?
Now that Pier seems somewhat stable, I'm starting to explore it more
as an application container with configurable widgets, digging it so
far, just need to get a few things done so I grok the do's and dont's a
little better. Great work though, keep it up!
Has anyone
done, or seen a sample of cascading dialog boxes done
with only magritte descriptions? Say I had a dropdown list of
classes, and when one was selected, I want the next drop down list
to contain methods in that class, or maybe countries and states, or
whatever. How can the second MultipleOptionDescription get it's
options: from the selector on the instance that the first
MultipleOptionDescription set the value on?
Yes, however you need to specify the second description on the
instance-side to be able to define it according to the state of your
model. There are some examples on how to change descriptions on an
instance-bases in the slides of my Magritte Tutorial (Dynamic
Descriptions, 31-33) at <http://www.lukas-renggli.ch/smalltalk/
magritte>.
Cheers,
Lukas
16 Apr
16 Apr
10:27 a.m.
New subject: Magritte
The draw-back,
there is usually one, would be that retrieving
the descriptions would be more expensive as they cannot be
cached anymore.
Why it can be cached anymore? Can't just be posible to refactor the
cache subsystem to work instance based intead of class based? I know that some systems allready have instance based
caches. Some
of them:
GOODS client by Avi Bryant,
rST,
OmniBase support
Yes, I know GOODS, it gets very slow when the caches grow. OmniBase
uses a slightly different approach and has its own fast
implementation of an IdentityDictionary.
PD: I'm not familiar with Magritte and recently
interested in it
because I
think it make archivable that an application could have a
maintainable web
interface and desktop interface at a reasonably cost.
True, however the builder for desktop-interfaces probably needs some
more work to be useable in production ;-)
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
10:30 a.m.
New subject: Magritte
Well, being slower, doesn't at all imply that
it's too slow, so a
better question is in the overall rendering of a page, say a
complex edit form, what percentage of total rendering time is taken
by retrieving the description both cached and uncached. I mean, it
could be dwarfed by the call to goods(or whatever db you use) to
actually retrieve the objects, and if that's the case, running
uncached may not even be noticeable.
Yes, this is true, it won't be noticeable at least for building GUIs:
the description is only read once before visiting the descriptions
and building the interface. It becomes more of a speed problem when a
query is done over a graph with many described objects.
Caching may not be necessary at all, in the larger
scheme of
things, and frankly, I find myself flushing the cache constantly,
especially during development.
Why that? The cache is automatically flushed when descriptions change
in your code.
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
10:32 a.m.
New subject: Magritte
Ok, doesn't seem to work, but let me explain what
I'm doing. I'm
writing a component meant to be hosted in Pier, the component has
several settings it needs, and I was using class side descriptions to
provide the "settings" interface that Pier offers on any component.
Yes, this is the usual procedure.
However, looking at PRSettingsComponent, I see that
it's not asking
the
instance for it's description, it's asking the class directly,
bypassing
any overrides I may have attempted on the instance side. Is that the
intention?
Oups, this seems to be a bug. I fixed it and will publish my changes
as soon as I have a propre internet connectionn again.
Am I writing components wrong? Should I be
subclassing
something in Pier rather than my own WAComponent subclass?
No nothing wrong from your side. You could also subclass PRStructure
(as the model) and define the settings on there (to make editing
work). Then you could also define views and other commands.
The Magritte tutorial is great btw, is there something
similar for
Pier?
No, not yet, only the SmallWiki paper from WikiSymposium that is
still valid for a big part (minus the name).
Now that Pier seems somewhat stable, I'm starting
to explore it more
as an application container with configurable widgets, digging it so
far, just need to get a few things done so I grok the do's and
dont's a
little better. Great work though, keep it up!
Thanks a lot!
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
6:04 p.m.
New subject: Magritte
The Magritte
tutorial is great btw, is there something similar for
Pier?
No, not yet, only the SmallWiki paper from WikiSymposium that is
still valid for a big part (minus the name).
10:16 p.m.
New subject: Magritte
Yes, this is true, it won't be noticeable at least
for building GUIs:
the description is only read once before visiting the descriptions
and building the interface. It becomes more of a speed problem when a
query is done over a graph with many described objects.
Ah, I hadn't considered querying.
things, and
frankly, I find myself flushing the cache constantly,
especially during development.
Why that? The cache is automatically flushed when
descriptions change
in your code.
18 Apr
18 Apr
6:51 p.m.
New subject: Magritte
The reason it is so slow is basically the use of
#allSelector, that could be
improved (with more clever code or pragmas). Still I guess the factor
of 10^3 would stay the same.
maybe putting all descriptions in a single class side method (a
Container) could do the job but that's not really nice ;)
Cédrick
6606
days inactive
6610
days old
21 comments
7 participants
participants (7)
-
Cédrick Béler -
Damien Cassou -
Hans N Beck -
Lukas Renggli -
Ramon Leon -
Ramon Leon -
Sebastián Sastre