Yeah, problems arise when there are relations and nested models. In the app
I'm working on at the moment there are at least 10 nested models that are
updated by a single "update" call, including insertion and deletion, pretty
complex. I ended up having something like model that also specifies how
i
I wrote a simple abstraction to automatically generate form based on the
given postgresql table definition.
I work well so far :)
On 30 Dec 2014 17:45, "Petr Kobalíček" wrote:
> Hi,
>
> you are right of course, nothing is "generally" wrong, but I hope you
> received the message. When you start u
Hi,
you are right of course, nothing is "generally" wrong, but I hope you
received the message. When you start using component oriented architecture
you won't need these selectors anymore as everything is handled by
components' themselves.
Qooxdoo is not declarative, that's also true, and this wa
This is my current implementation (in coffeescript, sorry):
###
# @ignore(_)
###
qx.Class.define 'util.Query',
type: 'static'
statics:
query: (filt) ->
objs = qx.core.ObjectRegistry.getRegistry()
_.chain(objs)
.pairs()
.filter((arr) -> filt(_.last(arr)))
.
Petr Kobalíček wrote
> I think that this CSS selector pattern is generally wrong, borrowed from
> HTML and jQuery style of doing things. You don't want to listen to all
> comboboxes I guess, what you want is model-driven architecture where you
> create a model and based on some declarative way the
I think that this CSS selector pattern is generally wrong, borrowed from
HTML and jQuery style of doing things. You don't want to listen to all
comboboxes I guess, what you want is model-driven architecture where you
create a model and based on some declarative way the library can create UI
for you
Derrell Lipman wrote
> Thanks, John. Yes, you're right. There is, however, a getRegistry() method
> that retrieves the __registry map. It should be fairly easy to write a
> function to search that map and create an array of the objects that match
> some condition. Coming up with the appropriate sea
thron7 wrote
> I'd recommend to think you are working in an object system, rather than in
> the DOM. What do you need those references for?
>
> If you want to change properties of a widget, make the containing widget
> maintain that through a stored reference.
>
> If you need to trigger changes b
I'd recommend to think you are working in an object system, rather than in
the DOM. What do you need those references for?
If you want to change properties of a widget, make the containing widget
maintain that through a stored reference.
If you need to trigger changes between unrelated objects (i
Thanks, John. Yes, you're right. There is, however, a getRegistry() method
that retrieves the __registry map. It should be fairly easy to write a
function to search that map and create an array of the objects that match
some condition. Coming up with the appropriate search condition may be a
little
It’s qx.core.ObjectRegistry, but it only supports lookup by hashcode
> On 29 Dec 2014, at 15:05, Derrell Lipman
> wrote:
>
> There is a widget registry. I'm on my phone and can't look it up, but try a
> search for qooxdoo widget registry and I bet you'll find it.
>
> Derrell
>
>
> On Mon, D
There is a widget registry. I'm on my phone and can't look it up, but try a
search for qooxdoo widget registry and I bet you'll find it.
Derrell
On Mon, Dec 29, 2014, 09:19 John Spackman wrote:
> AFAIK the answer is no. With single page apps a single list of all
> widgets could quickly get dif
AFAIK the answer is no. With single page apps a single list of all widgets
could quickly get difficult to handle with css style queries, the best practice
would therefore be to use OO design techniques. You can access the root
application by qx.core.Init.getApplication(), so if it had a proper
13 matches
Mail list logo
