New hierarchy: WebWindow, WebWidget, WebApplication
Locked
New hierarchy: WebWindow, WebWidget, WebApplication
 
|
And here are my current thougs to rearange WebElement hierarchy to
better serve the fortcoming tree-like control flow and specially stackable windows (also for Single page apps): 1. class hierarchy: WebElement WebWidget WebWindow has one WebForm (or includes form itself? drop WebForm?) WebPage WebApplication WebContext 2.1. Example composition, for just main view, no popups WebApplication WebContext WebPage WebElement WebWidget WebElement 2.2 Example composition, for one popup window, main view WebApplication WebContext (first context) WebPage WebContext (as subcontext in chain from first context above WebWindow (for popup, as part WebPage in first context above) 3. comments: WebApplication a standalone class, instead of subclass of current WebPage WebApplication is in crossroads of two "forces": 1. WebApplication is a presentation for one domain object, with many views 2. on the other side WebApplication makes a web page for each view, which is composed of WebElements and also WebWidgets Introduction of WebWindow to deal with stackable windows inside one web page (also for Single page apps). First window is a page itself. WebPage is therefore a subclass of WebWindow. Every popup then opens a new WebWindow. Each window has one WebForm Also every view in WebApplication has has its own WebPage (in its WebContext) What do you think, shall I go that way? Janko -- Janko Mivšek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565 _______________________________________________ Aida mailing list [hidden email] http://lists.aidaweb.si/mailman/listinfo/aida |
Re: New hierarchy: WebWindow, WebWidget, WebApplication
|
|
Hello Janko,
I think this is a really good idea. Could you please also briefly explain what are the contexts good for and how they work? Thank you. Kind regards, Jarda 2009/7/12 Janko Mivšek <[hidden email]>: > And here are my current thougs to rearange WebElement hierarchy to > better serve the fortcoming tree-like control flow and specially > stackable windows (also for Single page apps): > > 1. class hierarchy: > > WebElement > WebWidget > WebWindow has one WebForm (or includes form itself? drop WebForm?) > WebPage > WebApplication > WebContext > > 2.1. Example composition, for just main view, no popups > > WebApplication > WebContext > WebPage > WebElement > WebWidget > WebElement > > 2.2 Example composition, for one popup window, main view > > WebApplication > WebContext (first context) > WebPage > WebContext (as subcontext in chain from first context above > WebWindow (for popup, as part WebPage in first context above) > > 3. comments: > > WebApplication a standalone class, instead of subclass of current WebPage > > WebApplication is in crossroads of two "forces": > > 1. WebApplication is a presentation for one domain object, with many views > 2. on the other side WebApplication makes a web page for each view, > which is composed of WebElements and also WebWidgets > > > Introduction of WebWindow to deal with stackable windows inside one web > page (also for Single page apps). First window is a page itself. WebPage > is therefore a subclass of WebWindow. Every popup then opens a new > WebWindow. Each window has one WebForm > > Also every view in WebApplication has has its own WebPage (in its > WebContext) > > > What do you think, shall I go that way? > > Janko > > > > -- > Janko Mivšek > Svetovalec za informatiko > Eranova d.o.o. > Ljubljana, Slovenija > www.eranova.si > tel: 01 514 22 55 > faks: 01 514 22 56 > gsm: 031 674 565 > > _______________________________________________ > Aida mailing list > [hidden email] > http://lists.aidaweb.si/mailman/listinfo/aida > Aida mailing list [hidden email] http://lists.aidaweb.si/mailman/listinfo/aida |
Re: New hierarchy: WebWindow, WebWidget, WebApplication
|
|
Ahoj Jarda,
Jaroslav Havlín pravi: > I think this is a really good idea. So your Single page approach is compatible with such structure, am I right? > Could you please also briefly explain what are the contexts good for > and how they work? So called web execution contexts provide the "context" in which every request "execute". This is to be as close as possible to usual control flow terminology. Each request flows inside one context and executes some action, being just to respond with a web page or part of it, or to change some state of the domain model. In case we have more than one window stacked on the same page it is good to separate contexts to each of those windows. This is specially needed for aka call:answer tree-like control flow, like in this example: WebDemoControlFlowApp>>actionMainDelete (self ask: self viewConfirmation) ifTrue: [self observee delete] Here we have the main page running in main context, which is then interrupted by the popup dialog window with contents of #viewConfirmation. This one runs in new context in a chain below the first context. New context also runs in a new Smalltalk process, while the first one is blocked on the semaphore until a dialog window closes and return the desired value. At that moment the original context resumes and made the desired action, delete in our case. That way we will achieve the same control flow as others do with continuations, just that without any special tricks but just with normal Smalltalk processes. I hope I clarify contexts a bit. But please ask more, we need to put on written as much as possible abut that. Best regards Janko > 2009/7/12 Janko Mivšek <[hidden email]>: >> And here are my current thougs to rearange WebElement hierarchy to >> better serve the fortcoming tree-like control flow and specially >> stackable windows (also for Single page apps): >> >> 1. class hierarchy: >> >> WebElement >> WebWidget >> WebWindow has one WebForm (or includes form itself? drop WebForm?) >> WebPage >> WebApplication >> WebContext >> >> 2.1. Example composition, for just main view, no popups >> >> WebApplication >> WebContext >> WebPage >> WebElement >> WebWidget >> WebElement >> >> 2.2 Example composition, for one popup window, main view >> >> WebApplication >> WebContext (first context) >> WebPage >> WebContext (as subcontext in chain from first context above >> WebWindow (for popup, as part WebPage in first context above) >> >> 3. comments: >> >> WebApplication a standalone class, instead of subclass of current WebPage >> >> WebApplication is in crossroads of two "forces": >> >> 1. WebApplication is a presentation for one domain object, with many views >> 2. on the other side WebApplication makes a web page for each view, >> which is composed of WebElements and also WebWidgets >> >> >> Introduction of WebWindow to deal with stackable windows inside one web >> page (also for Single page apps). First window is a page itself. WebPage >> is therefore a subclass of WebWindow. Every popup then opens a new >> WebWindow. Each window has one WebForm >> >> Also every view in WebApplication has has its own WebPage (in its >> WebContext) >> >> >> What do you think, shall I go that way? >> >> Janko >> >> >> >> -- >> Janko Mivšek >> Svetovalec za informatiko >> Eranova d.o.o. >> Ljubljana, Slovenija >> www.eranova.si >> tel: 01 514 22 55 >> faks: 01 514 22 56 >> gsm: 031 674 565 >> >> _______________________________________________ >> Aida mailing list >> [hidden email] >> http://lists.aidaweb.si/mailman/listinfo/aida >> > _______________________________________________ > Aida mailing list > [hidden email] > http://lists.aidaweb.si/mailman/listinfo/aida > -- Janko Mivšek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565 _______________________________________________ Aida mailing list [hidden email] http://lists.aidaweb.si/mailman/listinfo/aida |
Re: New hierarchy: WebWindow, WebWidget, WebApplication
|
|
Hello Janko.
> So your Single page approach is compatible with such structure, am I right? There are still some differences. In the current single-page implementation, every element is stateful. But, as you said, the new naming is similar to other frameworks and it can make learning Aida easier for new developers. > I hope I clarify contexts a bit. But please ask more, we need to put on > written as much as possible abut that. Thank you for the explanation. It is clear to me now, and it sounds great. Especially the #ask: method will be very useful. It seems that if Aida provides stateful widgets, single-page library is not needed any more. I'm still working on a basic tutorial for single-page library, and I will try to create a website on top of it. I am also going to explore the new features in Aida. Then, I hope, we will be able to decide whether it is worth continuing with SP library. Cheers, Jarda 2009/7/12 Janko Mivšek <[hidden email]>: > Ahoj Jarda, > > Jaroslav Havlín pravi: > >> I think this is a really good idea. > > So your Single page approach is compatible with such structure, am I right? > >> Could you please also briefly explain what are the contexts good for >> and how they work? > > So called web execution contexts provide the "context" in which every > request "execute". This is to be as close as possible to usual control > flow terminology. > > Each request flows inside one context and executes some action, > being just to respond with a web page or part of it, or to change some > state of the domain model. > > In case we have more than one window stacked on the same page it is good > to separate contexts to each of those windows. This is specially needed > for aka call:answer tree-like control flow, like in this example: > > WebDemoControlFlowApp>>actionMainDelete > > (self ask: self viewConfirmation) > ifTrue: [self observee delete] > > Here we have the main page running in main context, which is then > interrupted by the popup dialog window with contents of > #viewConfirmation. This one runs in new context in a chain below the > first context. New context also runs in a new Smalltalk process, while > the first one is blocked on the semaphore until a dialog window closes > and return the desired value. At that moment the original context > resumes and made the desired action, delete in our case. > > That way we will achieve the same control flow as others do with > continuations, just that without any special tricks but just with normal > Smalltalk processes. > > I hope I clarify contexts a bit. But please ask more, we need to put on > written as much as possible abut that. > > Best regards > Janko > > > 2009/7/12 Janko Mivšek <[hidden email]>: >>> And here are my current thougs to rearange WebElement hierarchy to >>> better serve the fortcoming tree-like control flow and specially >>> stackable windows (also for Single page apps): >>> >>> 1. class hierarchy: >>> >>> WebElement >>> WebWidget >>> WebWindow has one WebForm (or includes form itself? drop WebForm?) >>> WebPage >>> WebApplication >>> WebContext >>> >>> 2.1. Example composition, for just main view, no popups >>> >>> WebApplication >>> WebContext >>> WebPage >>> WebElement >>> WebWidget >>> WebElement >>> >>> 2.2 Example composition, for one popup window, main view >>> >>> WebApplication >>> WebContext (first context) >>> WebPage >>> WebContext (as subcontext in chain from first context above >>> WebWindow (for popup, as part WebPage in first context above) >>> >>> 3. comments: >>> >>> WebApplication a standalone class, instead of subclass of current WebPage >>> >>> WebApplication is in crossroads of two "forces": >>> >>> 1. WebApplication is a presentation for one domain object, with many views >>> 2. on the other side WebApplication makes a web page for each view, >>> which is composed of WebElements and also WebWidgets >>> >>> >>> Introduction of WebWindow to deal with stackable windows inside one web >>> page (also for Single page apps). First window is a page itself. WebPage >>> is therefore a subclass of WebWindow. Every popup then opens a new >>> WebWindow. Each window has one WebForm >>> >>> Also every view in WebApplication has has its own WebPage (in its >>> WebContext) >>> >>> >>> What do you think, shall I go that way? >>> >>> Janko >>> >>> >>> >>> -- >>> Janko Mivšek >>> Svetovalec za informatiko >>> Eranova d.o.o. >>> Ljubljana, Slovenija >>> www.eranova.si >>> tel: 01 514 22 55 >>> faks: 01 514 22 56 >>> gsm: 031 674 565 >>> >>> _______________________________________________ >>> Aida mailing list >>> [hidden email] >>> http://lists.aidaweb.si/mailman/listinfo/aida >>> >> _______________________________________________ >> Aida mailing list >> [hidden email] >> http://lists.aidaweb.si/mailman/listinfo/aida >> > > -- > Janko Mivšek > Svetovalec za informatiko > Eranova d.o.o. > Ljubljana, Slovenija > www.eranova.si > tel: 01 514 22 55 > faks: 01 514 22 56 > gsm: 031 674 565 > > _______________________________________________ > Aida mailing list > [hidden email] > http://lists.aidaweb.si/mailman/listinfo/aida > Aida mailing list [hidden email] http://lists.aidaweb.si/mailman/listinfo/aida |
«
Return to AIDA/Web
|
1 view|%1 views
| Free forum by Nabble | Edit this page |