Modal dialogs that appear with their "background"

Hi there,

We would like methods similar to those that invoke the standard seaside
dialogs (like inform:) - but with a twist. We'd like the dialog to be
displayed WITH the current component instead of replacing it. (This is
basically the same visual effect that a JQuery ui dialog have, but
without any javascript involved.)

I am fairly new to seaside, so this is also a learning experience...

Our current solution works, but it seems to be the wrong way to go about
it. I am looking for a better way. This is all happening on Pharo 1.4
and Seaside 3.0.7

The current solution involves inheriting from WADelegation, and
overriding its renderContentOn: to render both the contents of the
dialog and also the previous component. This new kind of WADelegation is
then used in a show:onAnswer:delegation: call.

What bothers me about it is that a Delegation is not supposed to be used
for rendering stuff...as I understand it.

I have been investigating creating a normal visual Decoration that is
created with knowledge of the current component. It is then added to a
WAFormDialog, which I want to call:

... or something like that.

What I currently have is the code below. If I omit "html render:
backgroundComponent" in DialogDecoration>>renderContentOn: below, the
control flow work (of course that the backgroundComponent is not
displayed...). As the code is here, pharo just seems to get hung up.

Other possibilities is to create a component that wraps the current one
& adds the WAFormDialog - and calling it - but this has the same effect.

Any help appeciated...

- Iwan

ask: aString
     ^ self call: (WAYesOrNoDialog new
             addMessage: aString;
             addDecoration: (DialogDecoration new
                     backgroundComponent: self;
                     yourself);
             yourself)

WADecoration subclass: #DialogDecoration
     instanceVariableNames: 'backgroundComponent'

DialogDecoration>>initialise
     super initialize.
     backgroundComponent := nil

DialogDecoration>>backgroundComponent: aComponent
     backgroundComponent := aComponent

DialogDecoration>>renderContentOn: html
     self renderNextOn: html
     html render: backgroundComponent.


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Is there a specific reason you don't want to use a WAComponent subclass to do this?

Stephan_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

We have very few call:'s left in our apps. Most navigation is done with announcements.
We use a session subclass that has an announcer and delegate to that.

You can find sample code in both Deltawerken (DESession & DEPageChoice) and QCMagritte
(QCSession & QCPageChoice).

You can find a pre-made image (for Pharo 2 and 3) at http://ci.inria.fr/pharo-contribution/QCMagritte

Stephan_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 04/06/2014 17:29, Stephan Eggermont wrote:
> Is there a specific reason you don't want to use a WAComponent subclass to do this?

Stephan,

Any solution should do, as long as we can call a method that blocks and
returns with the answer. I did try with a WAComponent also that embeds
the current component, but with similar results.

I will have a look at your code as mentioned in your other email too. In
the mean time, I have come up with something that works. Not sure how
idiomatic this is of seaside though:

WAComponent subclass: #DialogHolder                   "An empty
component that can be replaced by the dialog later"


WADecoration subclass: #DialogDecoration            "A Decoration that
adds a DialogHolder to its decoratedComponent"
     instanceVariableNames: 'holder'

DialogDecoration>>initialize
     super initialize.
     holder := DialogHolder new

DialogDecoration>>renderContentOn: html
     html render: holder.
     self renderNextOn: html

DialogDecoration>>holder
     ^ holder

Then, the method that makes it appear, on a WAComponent subclass:

ask: aString
     | dialog answer |
     dialog := DialogDecoration new.
     self session presenter addDecoration: dialog.
     answer := dialog holder
         call:
             (WAYesOrNoDialog new
                 addMessage: aString;
                 yourself).
     self session presenter removeDecoration: dialog
     ^answer

Regards
- Iwan

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

I normally find/feel QCMagritte has a lot of things I could use, but
with scarce documentation it is really difficult to me to know where
to start with.

Would you provide a simple example of how to replace #call:/show: with
announcements?

Regards!

Esteban A. Maringolo


2014-06-04 12:51 GMT-03:00 Stephan Eggermont <[hidden email]>: _______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

EstebanAM wrote:
>I normally find/feel QCMagritte has a lot of things I could use, but
>with scarce documentation it is really difficult to me to know where
>to start with.

Good point. We'll try to put something together.

>Would you provide a simple example of how to replace #call:/show: with
>announcements?

In the meantime you can take a look at StoryBoard, that does exactly the same
but then with Deltawerken.

That is exactly what the pagechoice components do. they have a collection of pages they
can show and switch when sent an announcement.

When initializing a component, we define the announcements that it should react to
by showing something different. In the homepage of storyboard, we by default
show the SBProjectOverview. SBProjectOverview has a method that announces
SBProjectTonen (show project), that will result in an SBProjectDashboard being
shown on a project.

In SBHomePage (a subclass of DEPagechoice) we have

SBHomePage>>initialize
        super initialize.
        self homepage: SBProjectOverview new;
                goHomeOn: SBProjectOverviewTonen;
                goHomeOn: DELoggedIn;
                yourself.
        self addPage: SBProjectStoryBoard new
                announcement: SBProjectTonen
                symbol: #project.
        self addPage: SBProjectTeamPage new
                announcement: SBProjectTeamWijzigen
                symbol: #project.
        self addPage: SBProjectDashboard new
                announcement: SBProjectDashboardTonen
                symbol: #project.
        self addPage: SBUsersView new
                announcement: SBBeheerTonen

so that reacts to
  SBProjectOverviewTonen, DELoggedIn, SBProjectTonen,
  SBProjectTeamWijzigen, SBProjectDashboardTonen and
  SBBeheerTonen.

By showing a different component.

To make that work, we have

DEPageChoice>>goHomeOn: announcement
        self announcer
                subscribe: announcement
                do: [ :ann | self currentPage: homepage ]

DEPageChoice>>addPage: page announcement: announcement symbol: aSymbol
        self addPage: page.
        self announcer
                subscribe: announcement
                do: [ :ann |
                        (ann perform: aSymbol) ifNotNil: [ page subject: (ann perform: aSymbol) ].
                        self currentPage: page]

DEPageChoice>>addPage: page announcement: announcement
        self addPage: page.
        self announcer
                subscribe: announcement
                do: [ :ann |
                        self currentPage: page.
                ]

DEPageChoice>>addPage: page
        self pages
                detect: [ :each | each = page ]
                ifNone: [ self pages add: page ].
        currentPage ifNil: [ currentPage := page ].
        ^page

DEPageChoice>>renderContentOn: canvas
        currentPage
                ifNil:  [ canvas text: 'Internal error in ', self class name ,': no current page set.' ]
                ifNotNil: [ canvas render: currentPage ]

The announcer comes from the superclass of DEPageChoice, DEComponent

DEComponent>>announcer
        ^self session announcer

To make that work you need a session with an Announcer

DESession>>announcer
        ^announcer ifNil: [ announcer := Announcer new ]


The project overview can then do the announcement to make the
homepage switch what page it shows.

SBProjectOverview>>showProject: aProject
        self announce: (SBProjectTonen on: aProject)

SBProjectOverview >>showBeheer
        ((self user class = SBAdministrator ) and: [self isLoggedIn]) ifTrue: [
                self announce: SBBeheerTonen]




_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

The reason we want to use announcements in the way described, is that we
want to maintain the Seaside component structure: a component has no
knowledge about its parent, only about its children. The component knows
how it wants to react to announcements sent by its children. So there is a
one-way dependency direction. The result is better reusability of components.

Stephan  
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Thanks Stephan.

I can understand the use of events instead of direct message sends,
because it decouples the components.
I'm aware of announcements since Vassily published it years ago, and I
like it, it's a reification of the event, like other languajes does
for the callbacks and alike.
One thing that I don't understand is why you have to create one class
per anouncement, instead of using a general class for showing (Tonen)
and modifying (the other :) ), passing the component class as
parameter.

Another thing that I don't understand is why in your example you
create all the pages beforehand, instead of creating them as they are
needed to be shown.

I can see you don't use #call:/#show: because you directly replace the
instVar showing the currentPage and render the component explicitely.
I don't fully understand the implications of calling render: directly
on a component, I'm doing that but for simple reusable parts, more as
"views" than full blown stateful components.

I haven't looked into the StoryBoard project though, so I'm speaking
only by looking at your code. Thank you for spending that much time
with your examples.

Regarding QC, I insist, I'm building traditional "business" apps with
Seaside, and lots of features I'm doing seems to be already
implemented in QC, but QC seems too broad to grasp, the only
documentation I found is a presentation in SlideShare. Maybe there's
more.

Thanks again.

--
Esteban A. Maringolo


2014-06-08 7:02 GMT-03:00 Stephan Eggermont <[hidden email]>: _______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

EstebanAM wrote:
>One thing that I don't understand is why you have to create one class
>per anouncement, instead of using a general class for showing (Tonen)
>and modifying (the other :) ), passing the component class as
>parameter.

Good point. Mostly because we didn't get real feedback on it before ;)
It started as a smaller example, and we tried to be more explicit.
It has grown a bit, and we should refactor this.
Having a separate class for each announcement is easier to follow
for people new to smalltalk than doing meta programming voodoo
with parameters. We have also not shown you

DEPageChoice>>addPage: page announcement: announcement subject: subject accessors: accessors
        self addPage: page.
        self announcer
                subscribe: announcement
                do: [ :ann |
                        | temp |
                        temp := subject.
                        accessors do: [ :each | temp := temp perform: each ].
                        page subject: temp.
                        self currentPage: page.
                ]
                for: self

>Another thing that I don't understand is why in your example you
>create all the pages beforehand, instead of creating them as they are
>needed to be shown.

If you are very careful about your design, you can do much more lazily.
We do use lazy creation, especially in the leave components.
Reacting to announcements in one subcomponent that come from another
subcomponent gets interesting when their parents have not been created
yet. We found already creating top level components often easier.

Stephan_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hi all,

I started a tutorial on QCMagritte. I used the seaside tutorial by James Foster (http://seaside.gemtalksystems.com/tutorial.html) as an example, as I believe it should be that easy to use QCMagritte.

I would appreciate it, if someone wants to give it a try. It would consider it a pro if you do not know (QC)Magritte, as I intend to start with the basics. I am now completed chapter 4: a simple todo application.

Cheers,
Diego

On 05 Jun 2014, at 15:16, Esteban A. Maringolo <[hidden email]> wrote:

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

And I forgot to tell how to start the tutorial. It is included in the newest version of QCMagritte, as a QCMagritte application. It can be found under QCMagritte/Tutorial, and when you load the tutorial group of the ConfigurationOfQCMagritte, it should be installed as default.

On 16 Jun 2014, at 20:57, Diego Lont <[hidden email]> wrote:

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside