[cells-devel] Re: Problem with request

Ken Tilton wrote:
OK, I have been thinking. We like the granularity, so these get-parameters -- er, why aren't they post parameters? -- should not be treated as they are now as definitive of all the data, they just signify specific updates to the model. So I am thinking we take a different approach and simply loop over the values received and SETF the model slots, which should be c-in or c?n if they need to calculate an interesting initial value for a field based on other info. I will play with this. Meanwhile, I see a parameter on the server that says output-chunking is true -- in the request handler instead of bunging them all into a single string can we just write them one at a time to page and trust hunch to chunk them? kt

Ken Tilton wrote:
I will play with this.
I get it! Hopefully this will be a great weekend, I am really going to tear into what Andy has accomplished and see if I can rig up something just a little more transparent. What I see is a pattern with a page having an attribute of X and then a widget for X that has a rule watching the parameter X. That works well (again my deliberate withholding of Cells doc fails to stop an adopter!) but I want to see if we can simply create a widget named X and have it all Just Work, eliminating what is not all that bad, viz., creating a parallel slot on the page instance. But that trick might get exciting if we get into arrays/lists where a page has two Xs as children -- well, it could be handled, but why not automate that? It gets trickier because we want a two-way exchange here -- maybe we have a c?n rule which when suitably provoked calculates a new initial default based on the user selecting an entirely new something-else in some other field. So sometimes when a value changes the Lisp model must be told, and sometimes the ajax model must be told. I think sorting /this/ out will make for a more interesting weekend and possibly have me extending Cells a little. kt
participants (2)
-
Frank Goenninger
-
Ken Tilton