[Laszlo-dev] application architecture

[Daniel Kim]

Chris,

First, let me forward you our partial solution. 
Again, its only appropriate for demo situations but maybe it will help you think of a better way :)

Second, I don't know if a page tag really isolates the problem of being able to scope the dataset unless you mean that each page node would have their namespace. I think an easier solution would be to allow the dataset node to occurr anywhere in the node heirarchy. This would have the benefit of not only being backwards compatible, but intuitive.

Daniel


On Feb 11, 2005 08:56 AM, Chris Gallo <cgallo at caci.com> wrote:

> Hi Daniel, thanks for your response. Yes, I think I get the workaround you 
> are using. Now that you confirm this problem, I think that laszlo needs to 
> have some kind of <page> (or <screen>) class, which can contain datasets, 
> classes, components, etc. Basically, it will act like a mini-canvas; when 
> the page is ripped down, everything associated will be destroyed/recreated 
> as well. At some point I'll dig around the source and see what it would 
> take to do this...What I invision is that the <page> tag would be similar 
> to the library tag; You would include the page file in your application, 
> and instantiate it as needed:
> page1.lzx:
> <page name="page1">
>         <dataset ..../>
>         ...components/classes....
> </page>
> main.lzx:
> <canvas>
>         <include href="page1.lzx"/>
>         <state apply="${some condition}">
>                 <page1 /> 
>         </state>
> </canvas>
> 
> Let me know what you think.
> 
> 
> 
> Daniel Kim <dkim at krosscore.com> 
> 02/10/2005 04:17 PM
> 
> To
> laszlo-dev at openlaszlo.org
> cc
> Chris Gallo <cgallo at caci.com>
> Subject
> Re: [Laszlo-dev] application architecture
> 
> 
> 
> 
> 
> 
> Hi Chris:
> 
> We ran  into this problem as well. I am submitting a partial solution to 
> this problem. The main bug in our system is because of a lack of some kind 
> of ondestruct event, it never knows when to clen itself up.
> 
> The way it works is you decare a NodeDataset which constructs a hidden 
> global dataset using a key. You substitute the node dataset and it 
> resolves itself back to the global dataset.
> 
> If you want I can shoot you over a copy of our library and some example 
> code, but it is not production quality. It will slowly memory leak . 
> 
> A solution to this would be a way to notify the node that its parent is 
> beging garbage collected so it can release its global  dataset.
> 
> Daniel
> dkim at krosscore.com
> 
> 
> 
> Chris Gallo <cgallo at caci.com>:
> 
> I am currently working up a laszlo demo of our teams project; It's
> basically a web app trying to be a windows app: Its a couple of frames,
> with a menu in the top frame. Selections from the menu load content in the
> main frame.
> To build a traditional pull-down menu driven app in laszlo, I've used two
> views to replace the frames. The top view contains a lazslo menu. The
> bottom view will contain a bunch of states which are only applied when the
> corresponding menu option is chosen. Each state contains a single instance
> of a class, which encapsulates a page. Each page class is contained in a
> library tag, and each page has multiple data sources driving multiple
> complex components.
> The issue I'm having is that the datasets pertaining to each page are
> created globally; It would be nice if they could somehow be contained
> within the page, and created/destroyed when the page was
> created/destroyed.
> Am I thinking about this the right way? Is there a better/different way to
> architect this kind of application? 
> 
> 
> 
> _______________________________________________
> Laszlo-dev mailing list
> Laszlo-dev at openlaszlo.org
> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev





-------------- next part --------------
A non-text attachment was scrubbed...
Name: multi_result.lzx
Type: application/octet-stream
Size: 1507 bytes
Desc: not available
Url : http://www.openlaszlo.org/pipermail/laszlo-dev/attachments/20050211/06c8e23d/multi_result.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: multi_result_example.lzx
Type: application/octet-stream
Size: 1287 bytes
Desc: not available
Url : http://www.openlaszlo.org/pipermail/laszlo-dev/attachments/20050211/06c8e23d/multi_result_example.obj