Master-details

> hackish me has an action method which in the end links to its own
> view.  This refreshes the whole page.
>
> actionAddPositionAdd
>        ||
>        self observee canAddSelectedPosition
>                ifTrue: [self observee addValidSelectedPosition.
>                                 self redirectToView: #addPosition.
>                                ^self] .
>        self observee canChangeSelectedPosition
>                ifTrue: [self observee changeValidSelectedPosition.
>                                  self redirectToView: #addPosition]
>                                  "The above refreshes the page"
>                ifFalse: [self showError: self observee lastError].
>

>
> AB> Your opinions, even very general one, are very welcome.
>
>
> Cheers,
>
> Herbert                            mailto:[hidden email]
>
> _______________________________________________
> Aida mailing list
> [hidden email]
> http://lists.aidaweb.si/mailman/listinfo/aida
>

> Hi Alex,
>
>
>
> AB> But how you know which object is selected? Looks like the observer
> AB> already know about selected object.
>
> by using addBlock for the column and then linking back to the view
> which displays the component. viewPositionen hands its name to the
> component, so the component can link back. Other views use the
> component and send their name. BTW I found the nice way to
> color a line via rowGreenIfTrue.
>

> So the purpose is to make the selected line green and to update
> another part of the view with the selection.
>
> selectedIdFromView does the magic which lets Smalltalk find out what
> was clicked in the browser.
>
> In my mail of March 21st to the list I attached a picture of this
> view.
>
> BTW I still hope that someone will find a more elegant solution. If
> you really need to select a cell (vs my whole row) in your grid you
> have to write a lot of code in that style. Maybe then it's time for us
> to come up with something better. At least it works as expected. Right
> now I'm not annoyed enough by my code to dig deeper into Aida or write
> up something more convenient.
>

> Alex, I have to understand your code first, then change what I
> wrote according to that.
>
> Don't waste time on it, maybe tomorrow I sy the opposite.
> HK> I learned "Engineering is the art to build what you want from things
> HK> you can get." long ago from Jerry Avins on comp.dsp :-))
>
> AB>> I have proposal to add some new behavior to Aida that I think can be helpful.
> AB>> Well, I think that WebElement can have such method:
>
> AB>> onClickDo: aBlock andUpdate: aWebElement
>
> HK> Much better, storing some code and invoking it on click actually is
> HK> how UI's are usually built. I use the browser as a UI to the
> HK> application. This point of view would be reflected even better by:
> snippedy snap...

> Hi Alex,
>
>
> AB> It's ok. I think I should describe my choice in more details, and I
> AB> had options with MessageSend in my mind too. So I can compare several
> AB> variants. But right now, it seems like I produce a lot of words in the
> AB> list.
>
> see it like this: we two keep the list busy right now and Nicholas
> will be interested in the topic in the near future.
>

> Herbert, Thank you for interest and nice words!
>
> 2009/4/13 Herbert König <[hidden email]>:
>> Hi Alex,
>>
>>
>> AB> It's ok. I think I should describe my choice in more details, and I
>> AB> had options with MessageSend in my mind too. So I can compare several
>> AB> variants. But right now, it seems like I produce a lot of words in the
>> AB> list.
>>
>> see it like this: we two keep the list busy right now and Nicholas
>> will be interested in the topic in the near future.
>>
>
> If you have any questions or disagrements I will be glad to hear.
>
>> AB> Anyway if you find this stuff interesting, please let me now,
>> AB> and I will describe why I chosen blocks.
>>
>> I read the how in the code and will never know the why if you don't
>> tell me. The why is more interesting.
>
> I have plans for tommorow(seems lake too late for today) to get into
> such topics:
> 1. Parameters round-trip. MessageSends. Blocks.
> 2. Where to store blocks. Global vs local.
> 3. Why we are not close to desktop GUI yet.
>
>>
>> I've started using your method (only found time on the train) and will
>> expand it on updating more than one element (which I need). I'm just
>
> I will think about updating several elements. But I think this will be
> a different beast. Anyway I will try to form my opinion.
>
>> slow and quite busy right now.
>>
>> As an aside, when I first heard about seaside my naive assumption was,
>> I just take any old GUI app, send it "asSeaside" and I'm done. Turned
>> out I was wrong :-)) Aida is closer than Seaside (imho) and
>
> Yes, it looks like mirrages are driving our industry :)
>
>> your proposal brings us another step closer.
>
> With community help I hope it will. Thank you for nice words :)
>
>
> All the best,
> Alex
>

> Le mardi 14 avril 2009 à 15:51 +0200, Michael Rueger a écrit :
>> nico wrote:
>> > Hi Alex,
>> >
>> > Be careful on Squeak with your blockclosure actions. Squeak doesn't
>> > support full closures, you may discover unexpected issues and strange
>> > behaviour soon.
>>
>> The newest Pharo images and VMs do :-)
>
> Yes, I know that, and it's a *great* improvement. Many thanks to all
> Pharo developpers. They are making a great Smalltalk.

> Hi Alex,
>
> Be careful on Squeak with your blockclosure actions. Squeak doesn't
> support full closures, you may discover unexpected issues and strange
> behaviour soon.
>
> One solution is to copy the #fixCallbackTemps from Seaside, but it would
> still only be a hack.
>
> Cheers!
>
> Nico
>
> Le mardi 14 avril 2009 à 13:12 +0300, Alex Baran a écrit :
>> Hi Herbert,
>>
>> Yesterday's tomorrow is today, and bellow my answer lay (sorry for pun)
>>
>> 1. Parameters round-trip. MessageSends. Blocks.
>> We have parameters, we send them abroad(to browser) and receive them
>> back as foreigners(as strings). We do all marshaling and demarshaling
>> stuff. But why we need such parameters "round trip" if they don't
>> change their values. Maybe we can tie parameters in one bundle and
>> send abroad only bundle id. So we can pack bundle with various stuff
>> and our "send bundle id" method will be unchanged, because the method
>> does not depend on bundle internals.
>> Let's look inside a bundle and figure all parts that often apears
>> inside of a bundle. Here we can find: receiver, action(method),
>> arguments. Well this stuff can be represented as a MessageSend.
>> The first problem with MessageSend is that we don't want to allow user
>> to invoke an arbitrary message(by hand-written url for example). We of
>> course can use the Aida way of adding prefixes (such as "view"). But
>> let's look closer at a MessageSend - it's some action with arguments.
>> But block can do it too, and without any arguments, because a
>> block(closure) can catch variables from an environment. Actually when
>> we create a MessageSend we do the same arguments capture by explicitly
>> passing arguments to a MessageSend constructor. Verbosity is the
>> second problem of MessageSend approach. But in case of block we don't
>> need to pass parameters explicitly to closure. And we don't need to
>> create separate method to handle simple cases, just use block. In case
>> of complicated case we just invoke method from closure with arguments
>> implicitly captured by closure. With closure user not allowed to use
>> arbitrary message, only registered closures can be reached, so no need
>> in such guards like suffixes.
>>
>> 2. Where to store blocks. Global vs local.
>> Components born and die, and blocks have their lifespan too. We can
>> have global registry of all blocks. But when to purge a registry from
>> unused blocks? Blocks supposed to handle a component events. If a
>> component die, so should component block(well, of course if a block is
>> not used outside of a component). Blocks that don't die can produce a
>> lot of garbage because they can have implicit arguments(captured at a
>> block creation). So it's natural to store a block inside of a
>> component, so they, like lucky spouses, will die in a one day.
>>
>> 3. Why we are not close to desktop GUI yet.
>> Well, because we need to explicitly send refresh to components. We
>> don't have luxury of communicating arbitrary refreshes back to a
>> browser. Component id is encoded in Ajax request and we supposed to
>> return update of that component. So such things like communicating by
>> means of value holders (or another kind of adapters) is not here. And
>> I think that value holders is a one of a good and very simple glues
>> that makes easier to define powerful components that have low
>> coupling. Maybe Comet can be of help here, but I'm unsure, anyway I'm
>> not in the topic yet. Right now I can not find such style of
>> cooperation inside of Aida. My mind is turning around how to make
>> request without component id, and have response with ids and htmls of
>> changed components. But here we have problem of collecting all changed
>> components.
>>
>> Regarding explicitly updating of several components, I'm in the
>> process of figuring it out.
>>
>>
>> Hope it helps,
>> Alex
>>
>> 2009/4/14 Alex Baran <[hidden email]>:
>> > Herbert, Thank you for interest and nice words!
>> >
>> > 2009/4/13 Herbert König <[hidden email]>:
>> >> Hi Alex,
>> >>
>> >>
>> >> AB> It's ok. I think I should describe my choice in more details, and I
>> >> AB> had options with MessageSend in my mind too. So I can compare several
>> >> AB> variants. But right now, it seems like I produce a lot of words in the
>> >> AB> list.
>> >>
>> >> see it like this: we two keep the list busy right now and Nicholas
>> >> will be interested in the topic in the near future.
>> >>
>> >
>> > If you have any questions or disagrements I will be glad to hear.
>> >
>> >> AB> Anyway if you find this stuff interesting, please let me now,
>> >> AB> and I will describe why I chosen blocks.
>> >>
>> >> I read the how in the code and will never know the why if you don't
>> >> tell me. The why is more interesting.
>> >
>> > I have plans for tommorow(seems lake too late for today) to get into
>> > such topics:
>> > 1. Parameters round-trip. MessageSends. Blocks.
>> > 2. Where to store blocks. Global vs local.
>> > 3. Why we are not close to desktop GUI yet.
>> >
>> >>
>> >> I've started using your method (only found time on the train) and will
>> >> expand it on updating more than one element (which I need). I'm just
>> >
>> > I will think about updating several elements. But I think this will be
>> > a different beast. Anyway I will try to form my opinion.
>> >
>> >> slow and quite busy right now.
>> >>
>> >> As an aside, when I first heard about seaside my naive assumption was,
>> >> I just take any old GUI app, send it "asSeaside" and I'm done. Turned
>> >> out I was wrong :-)) Aida is closer than Seaside (imho) and
>> >
>> > Yes, it looks like mirrages are driving our industry :)
>> >
>> >> your proposal brings us another step closer.
>> >
>> > With community help I hope it will. Thank you for nice words :)
>> >
>> >
>> > All the best,
>> > Alex
>> >
>> _______________________________________________
>> Aida mailing list
>> [hidden email]
>> http://lists.aidaweb.si/mailman/listinfo/aida
>
> _______________________________________________
> Aida mailing list
> [hidden email]
> http://lists.aidaweb.si/mailman/listinfo/aida
>
>