Alexander Klimetschek napisał(a):
Great, I'd love to have a postable source. How far are you? I could help
you in testing it next week, when I have our webapp running with Cocoon
trunk (going from dojo 0.3.1 to 0.4.1 is quite some work...).
Specifically I want to reuse lots of styling
Grzegorz Kossakowski schrieb:
I hope to commit some basic (without caching implemented) code within days. It
took me quite a long time to clarify
whole idea...
Great!
You mentioned that you play with Dojo. I have some troubles with fixing upload
progress sample from Forms. I guess it's
Grzegorz Kossakowski schrieb:
For now, just digging into the code is the only option IMO.
Ok, I will have a look at it next week.
I'm busy with other stuff (postable source especially) so will not
be able to do this.
Great, I'd love to have a postable source. How far are you? I could help
Alexander Klimetschek napisał(a):
Grzegorz Kossakowski schrieb:
I could easily create the patch for the warning message.
Regarding the other solution (automatically resolving the circular dep
and thus allowing it): I would now agree to skip this. A bit of
research showed that generic
On 4/4/07, Grzegorz Kossakowski [EMAIL PROTECTED] wrote:
Alexander Klimetschek napisał(a):
Grzegorz Kossakowski schrieb:
We do need the circular dependency: the basic principle is a super
block that runs cforms that are mainly defined in a child block - the
model lies in the child block
Grzegorz Kossakowski schrieb:
In short: I mean that super should work as fallback mechanism. I guess
it does not work that way now. However, this would eliminate need for
circular dependencies and give cleaner design.
What do you think?
Yes, this would indeed be better. The super block must
Rice Yeh napisał(a):
The idea directly applies to OO's inheritance definition. However,
it might not be easy to implement because it is hard to define the
looked-up resource does not exist in the extending servlet. Take
flowscript as example, it is usually a javascript error when calling a
Alexander Klimetschek napisał(a):
Yes, this would indeed be better. The super block must not know of its
concrete children, but be able to call polymorphic matchers - true OO.
Then I can remove the cyclic dep.
Alex
BTW: When I started to use blocks and especially using the inheritance
Grzegorz Kossakowski schrieb:
Alexander Klimetschek napisał(a):
Yes, this would indeed be better. The super block must not know of its
concrete children, but be able to call polymorphic matchers - true OO.
Then I can remove the cyclic dep.
Alex
BTW: When I started to use blocks and especially
Oh, I got it: there was a circular dependency in the servlet connections (A
using B, B using A as super). It did work with the old block servlets, but
now you get the very unhelpful exception. I don't think we actually need
this circular connection in particular. But generally, two solutions
Alexander Klimetschek napisał(a):
Oh, I got it: there was a circular dependency in the servlet connections
(A using B, B using A as super). It did work with the old block
servlets, but now you get the very unhelpful exception. I don't think we
actually need this circular connection in
Grzegorz Kossakowski schrieb:
My opinion is that circular dependencies should not be allowed and I
agree that more meaningful exception is needed here.
We do need the circular dependency: the basic principle is a super block
that runs cforms that are mainly defined in a child block - the
Alexander Klimetschek napisał(a):
Grzegorz Kossakowski schrieb:
We do need the circular dependency: the basic principle is a super
block that runs cforms that are mainly defined in a child block - the
model lies in the child block and it contains a selection-list whose
source is
13 matches
Mail list logo
