StephenSmith
10-23-2005, 02:26 PM
Edit: 23/11/05
Hi,
I've essentially deleted this original post for a couple of reasons. Most importantly, the main idea in it has been superceeded by some neat functionality in the new version 3.1 of Laszlo, namely local datasets. My approach also had limitiations, such as the lack of certain events and the use of xpaths to set the top-level datapath.
Secondly, it had a Hashmap implementation that was totally unnessesary. LzParam does the exact same thing, but better. So, that's gone.
Finally, it had so many keywords, it was showing up in all my forum searches. That annoyed me, and it's my post! It must have bugged a few of you I'm sure... ;)
However, there was one thing I reckon worth saving, and I'm no real fan of throwing everything down the memory hole. It's an idea for executing specific code on the reception of queries, allowing you do to specific things with the data without having to mess with creating and deleting delegates.
Basically, the idea is that you write a submit method that takes, for example, a LzDelegate or a Javascript object with a specific method in it's proto (google "proto javascript class" for info on creating your own classes in pure JS). This object/delegate might perhaps copy the data to a specific pointer provided by the component making the request. When the request is made, a unique incremental ID is assigned to it by the helper method. This object/delegate is stored in the Hashmap (i.e. LzParams object), using the ID as a key. It is also added to the query string prior to the actual submit.
The remote app/script then does the request as usual but also echos back the request ID in some way. As it's per-client unique, it's a no-brainer to do. Back in Laszlo Land, the ondata of the dataset has a generic method to:
extract the request ID from the result
retrieve (and remove) the object from the hashtable for that request ID
execute it in whatever way you desire depending on your implementation.
I've found this to be really useful and worth sharing. I'm using it to allow gui components lookup specific data via a buffer dataset. The delegate I'm passing knows exactly where to place the data for the specific control that requested it, meaning that the gui updates seamlessly. Enable request queuning and Laszlo does most of the work for you.
If you are working with a massive dataset, you only download what is needed. For example, you could have a tree that retrieved subnodes only when it was expanded. And so on. I give each large GUI section it's own bufferset to keep things snappy.
Hope this helps someone!
Hi,
I've essentially deleted this original post for a couple of reasons. Most importantly, the main idea in it has been superceeded by some neat functionality in the new version 3.1 of Laszlo, namely local datasets. My approach also had limitiations, such as the lack of certain events and the use of xpaths to set the top-level datapath.
Secondly, it had a Hashmap implementation that was totally unnessesary. LzParam does the exact same thing, but better. So, that's gone.
Finally, it had so many keywords, it was showing up in all my forum searches. That annoyed me, and it's my post! It must have bugged a few of you I'm sure... ;)
However, there was one thing I reckon worth saving, and I'm no real fan of throwing everything down the memory hole. It's an idea for executing specific code on the reception of queries, allowing you do to specific things with the data without having to mess with creating and deleting delegates.
Basically, the idea is that you write a submit method that takes, for example, a LzDelegate or a Javascript object with a specific method in it's proto (google "proto javascript class" for info on creating your own classes in pure JS). This object/delegate might perhaps copy the data to a specific pointer provided by the component making the request. When the request is made, a unique incremental ID is assigned to it by the helper method. This object/delegate is stored in the Hashmap (i.e. LzParams object), using the ID as a key. It is also added to the query string prior to the actual submit.
The remote app/script then does the request as usual but also echos back the request ID in some way. As it's per-client unique, it's a no-brainer to do. Back in Laszlo Land, the ondata of the dataset has a generic method to:
extract the request ID from the result
retrieve (and remove) the object from the hashtable for that request ID
execute it in whatever way you desire depending on your implementation.
I've found this to be really useful and worth sharing. I'm using it to allow gui components lookup specific data via a buffer dataset. The delegate I'm passing knows exactly where to place the data for the specific control that requested it, meaning that the gui updates seamlessly. Enable request queuning and Laszlo does most of the work for you.
If you are working with a massive dataset, you only download what is needed. For example, you could have a tree that retrieved subnodes only when it was expanded. And so on. I give each large GUI section it's own bufferset to keep things snappy.
Hope this helps someone!