On Dom, 29 de Mayo de 2005, 7:18, Sylvain Wallez dijo:
> Antonio Gallardo wrote:
>
>>Hi, It's me again!
>>
>>BTW, dunno, if I am asking to much from cforms? Sorry if this is the
>> case.
>>:-)
>
> Asking too much? Hey Antonio, CForms is powerful because it answers its
> user's needs!
lol.
I was not working with cocoon in the last 6 months. I did the comment,
because I am wondering why nobody before me found we need to improve the
selectionList performance at all. Is everybody happy and only me are not?
;-)
Hmm, if this the case, it makes me wonder if I am using cforms in the
right way at all! Perhaps I need to register myself for some cforms
courses. :-)
am I stressing to much cforms? This question is in my head now. Sorry.
>>Question: In definition.xml, how in javascript code we can set an
>>attribute? Or I want to know how to build programatically a DSL like:
>>
>><fd:selection-list src="cocoon:/myDSL.data" dynamic="true"/>
>>
>>I know we often use this:
>>
>>myWidget.setSelectionList("cocoon:/myDSL.data?id=" + value);
>>
>>But how to make the above line @dynamic? I am asking because soon I will
>>need to set also @cache. ;-)
>>
>>
>
> When you call setSelectionList with a URI, it is implicitely dynamic. So
> you're not asking too much, it's already there!
>
> And following the principle of least surprise, this should IMO be the
> default behavior, i.e. the default value for the "dynamic" attribute
> should be false. Only if people know that the URI has to be loaded
> statically should they have to say dynamic="false" to have a better
> performance.
>
> WDYT?
I agree. Everything in cocoon is dyamic. We use cforms mostly to build
dynamic websites. ;-)
Well, from a DB POV I agree, there are more often DSL than SSL. But I am
not sure if the rest of the people will feel comfortable to define by
default dynamic="true". BTW, if this is the default, then why not better
rename @dynamic to @static? Then to make a SSL we need to use
static="true"
wich makes more sense and is equivalent to @dynamic="false".
I know, one argument against this change is: backward compatibility, but
since cforms is unstable, need we to care? I also know we are trying to
not break compatibility too much. And it does not. We can use the
Deprecation logger for inform users.
Note, I am not pushing a lot about this name change. I am not too much
pendatic in names (my fault). If people want to stay with @dynamic is OK
to me too.
Before starting coding, I will write down a resume of what and how we want
to do the changes on the SeletionsLists behavior. To allow people comment
again the proposed solution.
Best Regards,
Antonio Gallardo.
