You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@apache.org> on 2006/08/01 17:41:00 UTC
[CForms] Streaming out widget attributes?
Hi,
I'm currently looking into a way of getting information for a widget in
my template that has been defined in the model. But it seems to me that
this is not possible right now.
Is anyone against streaming out all attributes of a widget in the
generateSaxFragment() method? As attributes are not used frequently I
think this shouldn't create problems.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [CForms] Streaming out widget attributes?
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Sylvain Wallez wrote:
> Antonio Gallardo wrote:
>> Sylvain Wallez escribió:
>>> - in complex use cases the GUI logic, as Carsten's use case
>>> exemplifies, becomes spread all over the pipeline, and it becomes
>>> increasingly difficult to understand what happens where.
>> Could you explain how can you do the Carsten need easily with Wicket?
>
> Sorry, no time to study this particular point. I'm expressing general
> feelings.
>
>>> - client/server communication with JSON makes it really easy to build
>>> Ajax apps, but is a pain to produce from Cocoon unless we directly
>>> send it from the controller, which actually makes Cocoon pipelines
>>> useless.
>> Why everything needs to go through pipelines?
>
> That's precisely the point: do you really need Cocoon if you have no
> pipelines? DWR perfectly does the trick in that case.
"unfortunatelly" yes. Nothing else gives you:
- powerful forms
- flow
- common application look
- easy i18n
I am almost not using pipelines in cocoon. My sitemap is identical for
almost all applications we wrote in 2 years. I would advise against
using xsps, logicsheets, mail sending pipelines and similar stuff. It is
way better to separate your application services to pure java and use
spring for that. If CForms were available as a separate block usable
from spring framework I would seriously consider this solution.
... But as it is not the case I will stick with cocoon and be happy
about that.
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [OT] Re: [CForms] Streaming out widget attributes?
Posted by Simone Gianni <s....@thebug.it>.
Leszek Gawron wrote:
> +1. Cocoon has become a web application framework a long time ago even
> though it's first steps were in other direction.
+100 :)
> Every web application at some point needs to use some variation of
> ValueList for displaying tabular data (70% of my GUIs are value lists,
> the rest are plain CForms for editing beans). I would be thrilled if
> we had some kind of ValueList component based on CForms that:
>
> - displays a value list consisting of several columns
> - allows for sortable columns (direction indicator and such)
> - displays some filtering form widgets
> - manages navigation
> - first, previous, next, last buttons
> - goto page button
> - set number of entries per page
> - is capable of rows selection
> - single
> - multiple
> - is capable of running value list events
> - e.g. ContactValueList would have: deleteSelected, addContact,
> editContact and such.
We are basically implementing all these features, but in cocoon forms
repeater itself, so that you can use it to display/edit even very large
sets of data. Sorting will surely be there, filtering we still don't
have clear ideas, page navigation is already there except for the goto
page, row selection is already present in cocoon forms repeater as well
as events.
Simone
--
Simone Gianni
>
> My current implementation is an utter crap (I am ashamed I am not able
> to come up with something more sophisticated).
>
> Going further: we could provide some kind of pattern for application
> menus and toolbars.
>
[OT] Re: [CForms] Streaming out widget attributes?
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Simone Gianni wrote:
> Sylvain Wallez wrote:
>
>> Antonio Gallardo wrote:
>>
>>>> - since only CForms has Ajax integration, people are over-using it
>>>> for presentation purposes (e.g. paginated repeater)
>>>
>>> I agree with you, mixing binding with form definition is not good. We
>>> want to keep it separated. However, I think it is a first
>>> implementation wich show us a way to implement a paginated repeater
>>> after all it is not released yet. It is a work in progress. Is not
>>> fair to blame to a first draft implementation.
> yes, but it's committed and asked for review :)
>
>> I don't blame any implementation, but think the concept is
>> criticizable. Using a form object model and flowscript to paginate a
>> result table seems overkill to me.
>
> While I think cocon should have ajax facilities not only in CForms (and
> implement some Wicket/Ruby/Gwt paradigms), producing a result table with
> cocoon forms seems reasonable to me because, in my experience :
> - The result is always following a "query", which quite often is created
> using a form before the result page, and the best way to do this is flow
> and forms.
> - Every other serious framework (including Swing or wicket) actually
> uses MVC also for displaying a table of results.
> - Even with no query parameters, the result list is often obtained with
> some complex logic (hibernate query, calling services, getting spring
> beans and so on).
> - Since the data you are displaying are usually been inserted by the
> user in some other page, you already have the widgets for them, so why
> rewrite all the stuff in jx + xsl and not reuse those widgets in output
> state?
> - The pagination we are implementing is not only for output but also for
> input, so that giving the user 50 rows in a repeater does not result in
> a 500kb page 3 screens long.
+1. Cocoon has become a web application framework a long time ago even
though it's first steps were in other direction. Every web application
at some point needs to use some variation of ValueList for displaying
tabular data (70% of my GUIs are value lists, the rest are plain CForms
for editing beans). I would be thrilled if we had some kind of ValueList
component based on CForms that:
- displays a value list consisting of several columns
- allows for sortable columns (direction indicator and such)
- displays some filtering form widgets
- manages navigation
- first, previous, next, last buttons
- goto page button
- set number of entries per page
- is capable of rows selection
- single
- multiple
- is capable of running value list events
- e.g. ContactValueList would have: deleteSelected, addContact,
editContact and such.
My current implementation is an utter crap (I am ashamed I am not able
to come up with something more sophisticated).
Going further: we could provide some kind of pattern for application
menus and toolbars.
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [CForms] Streaming out widget attributes?
Posted by Simone Gianni <s....@thebug.it>.
Sylvain Wallez wrote:
> Antonio Gallardo wrote:
>
>>> - since only CForms has Ajax integration, people are over-using it
>>> for presentation purposes (e.g. paginated repeater)
>>
>>
>> I agree with you, mixing binding with form definition is not good. We
>> want to keep it separated. However, I think it is a first
>> implementation wich show us a way to implement a paginated repeater
>> after all it is not released yet. It is a work in progress. Is not
>> fair to blame to a first draft implementation.
>
yes, but it's committed and asked for review :)
>
> I don't blame any implementation, but think the concept is
> criticizable. Using a form object model and flowscript to paginate a
> result table seems overkill to me.
While I think cocon should have ajax facilities not only in CForms (and
implement some Wicket/Ruby/Gwt paradigms), producing a result table with
cocoon forms seems reasonable to me because, in my experience :
- The result is always following a "query", which quite often is created
using a form before the result page, and the best way to do this is flow
and forms.
- Every other serious framework (including Swing or wicket) actually
uses MVC also for displaying a table of results.
- Even with no query parameters, the result list is often obtained with
some complex logic (hibernate query, calling services, getting spring
beans and so on).
- Since the data you are displaying are usually been inserted by the
user in some other page, you already have the widgets for them, so why
rewrite all the stuff in jx + xsl and not reuse those widgets in output
state?
- The pagination we are implementing is not only for output but also for
input, so that giving the user 50 rows in a repeater does not result in
a 500kb page 3 screens long.
>
>>> Cocoon allows lots of non-Java people to build complicated stuff,
>>> and this is a major achievement. But I find it easier to write Java
>>> if you're fluent with it rather than finding workarounds in an
>>> XML-centric framework.
>>
>> I feel myself fluent in Java and I still prefer find faster to write
>> a cform application using with cocoon. ;-)
>
>
> That's why there's no single silver bullet and one-size-fits-all
> framework!
Being fluent in java allows me to use Javaflow, which is much much
better than javascript, and java components, and still have non java
fluent people take care of presentation and "page" developement. This
can obviously be done in wicket as well, but being the java fluent guy
in wicket means taking care of much more stuff (gui, mandatory fields,
validation) than being the javaflow guy in a cocoon application where
you can focus only on control, eventually binding and backend logic.
Simone
Re: [CForms] Streaming out widget attributes?
Posted by Sylvain Wallez <sy...@apache.org>.
Antonio Gallardo wrote:
> Sylvain Wallez escribió:
>> - in complex use cases the GUI logic, as Carsten's use case
>> exemplifies, becomes spread all over the pipeline, and it becomes
>> increasingly difficult to understand what happens where.
> Could you explain how can you do the Carsten need easily with Wicket?
Sorry, no time to study this particular point. I'm expressing general
feelings.
>> - client/server communication with JSON makes it really easy to build
>> Ajax apps, but is a pain to produce from Cocoon unless we directly
>> send it from the controller, which actually makes Cocoon pipelines
>> useless.
> Why everything needs to go through pipelines?
That's precisely the point: do you really need Cocoon if you have no
pipelines? DWR perfectly does the trick in that case.
>> - Dojo widgets are a nice replacement for CForm's styling
>> stylesheets, reduce the server load, and again make pipelines less
>> useful.
>
> Here is a trade off dojo reduce the server load but increase the
> client load and bandwidth:
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&w=2&r=1&s=dojo+fat&q=b
> I am not telling dojo is bad, I like it, but I see here is a trade
> off. Dojo usage is not a free lunch after all. ;-)
You don't get my point. Dojo can be optimized and aggressively cached on
the browser. Once cached in the browser, the concrete things the server
has to do are reduced.
>> - enhancing the CForms styling leads to a giant XSL (even if
>> modularized) where every possible styling used in the application
>> must be present.
>
> It's not my experience. xslt allows us to just overwrite the required
> pieces to enhance the styling.
Sure, but this doesn't mean its readable nor maintainable when you have
so many templates and need to use priorities.
>> - since only CForms has Ajax integration, people are over-using it
>> for presentation purposes (e.g. paginated repeater)
>
> I agree with you, mixing binding with form definition is not good. We
> want to keep it separated. However, I think it is a first
> implementation wich show us a way to implement a paginated repeater
> after all it is not released yet. It is a work in progress. Is not
> fair to blame to a first draft implementation.
I don't blame any implementation, but think the concept is criticizable.
Using a form object model and flowscript to paginate a result table
seems overkill to me.
>> Don't get me wrong: Cocoon is a killer for publication. But for
>> webapps, other approaches, more Java-centric, are worth considering.
>> My current choice is Wicket, which was just proposed for incubation.
>
> I took a fast look at wicket and I can see an analogy to building a
> form intensive application with XSP logicsheets. I already went this
> way and I can say it is not not easy to maintain the code. I mean it
> is the same code embedding concept with a new syntax sugar after all.
Not at all. There's no code embedding. It's more like writing a Swing
GUI that would be associated to an HTML template that defines its layout.
>> Cocoon allows lots of non-Java people to build complicated stuff, and
>> this is a major achievement. But I find it easier to write Java if
>> you're fluent with it rather than finding workarounds in an
>> XML-centric framework.
> I feel myself fluent in Java and I still prefer find faster to write a
> cform application using with cocoon. ;-)
That's why there's no single silver bullet and one-size-fits-all framework!
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: [CForms] Streaming out widget attributes?
Posted by Antonio Gallardo <ag...@agssa.net>.
Matthias Epheser escribió:
> Antonio Gallardo schrieb:
>> Sylvain Wallez escribió:
>>> - since only CForms has Ajax integration, people are over-using it
>>> for presentation purposes (e.g. paginated repeater)
>> I agree with you, mixing binding with form definition is not good. We
>> want to keep it separated. However, I think it is a first
>> implementation wich show us a way to implement a paginated repeater
>> after all it is not released yet. It is a work in progress. Is not
>> fair to blame to a first draft implementation.
>
> I had my thoughts whether the mixing is appropriate or not from the
> start, so thank you for your feedback.
Hi,
I am sorry for to things:
1. The way you got the feedback
2. The late of my reply.
>
> As Simone mentioned in his reply, our main goal was to achieve the
> lazy-loading of pages. I agree that using the standard binding to
> fetch all rows and just display a subset (page) of them could be
> easily done with some simple xsl and without changes in the repeater
> implementation at all. But we are not focused just on presentation.
> Our implementation is a try to load only the row-data we need to
> support persistency frameworks and large collections in general.
> Currently lazy loading could be achieved without changes in the
> controller except using the advanced collection. Editing data is also
> possible yet, adding and deleting of rows will follow.
>
> So concerning this I think pageSave/pageLoad has to be done in the
> binding because we have to control the doLoad()-method and prevent it
> from fetching and creating all rows from the start. To ensure
> seperation of concerns we can maybe try to move everything to the
> binding.
A RT: We may extend the repeater with an interface to fetch and store
data in different O/R tools. ie: OJB [1], JDO, ibatis [3], etc.
>
> Currently the form-definition is used to enable pagination and and
> setting pageSize and so on. This configuration tag could be easily
> moved to the binding definition file without problems.
Sure.
> The binding registers its pageStorage object in the repeater object
> just for one purpose. In the change-page-action I need to call
> pageSave and pageLoad.
Yep. This is also the same as for an ajax enabled application when you
try to stay in ajax mode as long as possible. By now, we are bundling as
a form attribute, the javascript flow formModel. This model allows us in
the form definition access the form binding framework. ie: in the
definition we wrote something like the next code to allow user to save
changes without living the form:
<fd:action id="save" validate="true">
<fd:label>Save</fd:label>
<fd:on-action>
<fd:javascript>
var formModel = form.getAttribute("process").form; // Get the
javascript form model
var facade = form.getAttribute("process").facade; // a bean
facade
formModel.save(facade);
facade.save();
}
</fd:javascript>
</fd:on-action>
</fd:action>
This way we are able to access the binding framework without a mix. I
don't know if this is the ugliest hack, but solved our needs. :-)
> If I manage to access these methods there directly without
> repeater.getStorage().doPageLoad() in a decent way, everything would
> work just using the binding and without touching the definition and
> the repeater itself.
>
> Please let me know what you think about it or if I'm getting something
> completely wrong.
Unfortunately, right now, I don't have an opinion out of hand. I think
AJAX form handling is a different beast than traditional MVC form
handling, hence we need to address it in a different way. Your effort
are well appreciated and we expect to help as much as is possible.
>
> Matthias
Best Regards,
Antonio Gallardo
[1] http://db.apache.org/ojb/
[2] http://db.apache.org/jdo/
[3] http://ibatis.apache.org/
Re: [CForms] Streaming out widget attributes?
Posted by Matthias Epheser <ma...@gmx.at>.
Antonio Gallardo schrieb:
> Sylvain Wallez escribió:
>> - since only CForms has Ajax integration, people are over-using it for
>> presentation purposes (e.g. paginated repeater)
> I agree with you, mixing binding with form definition is not good. We
> want to keep it separated. However, I think it is a first implementation
> wich show us a way to implement a paginated repeater after all it is not
> released yet. It is a work in progress. Is not fair to blame to a first
> draft implementation.
I had my thoughts whether the mixing is appropriate or not from the
start, so thank you for your feedback.
As Simone mentioned in his reply, our main goal was to achieve the
lazy-loading of pages. I agree that using the standard binding to fetch
all rows and just display a subset (page) of them could be easily done
with some simple xsl and without changes in the repeater implementation
at all. But we are not focused just on presentation. Our implementation
is a try to load only the row-data we need to support persistency
frameworks and large collections in general. Currently lazy loading
could be achieved without changes in the controller except using the
advanced collection. Editing data is also possible yet, adding and
deleting of rows will follow.
So concerning this I think pageSave/pageLoad has to be done in the
binding because we have to control the doLoad()-method and prevent it
from fetching and creating all rows from the start. To ensure seperation
of concerns we can maybe try to move everything to the binding.
Currently the form-definition is used to enable pagination and and
setting pageSize and so on. This configuration tag could be easily moved
to the binding definition file without problems. The binding registers
its pageStorage object in the repeater object just for one purpose. In
the change-page-action I need to call pageSave and pageLoad. If I manage
to access these methods there directly without
repeater.getStorage().doPageLoad() in a decent way, everything would
work just using the binding and without touching the definition and the
repeater itself.
Please let me know what you think about it or if I'm getting something
completely wrong.
Matthias
Re: [CForms] Streaming out widget attributes?
Posted by Antonio Gallardo <ag...@agssa.net>.
Sylvain Wallez escribió:
> [resent -- seems to have been lost]
>
> Reinhard Poetz wrote:
>> Sylvain Wallez wrote:
>>> I'm sorry to say that over time, I found Cocoon to be more an
>>> obstactle for complex webapps pages (not talking about flow) than a
>>> real help, and that's why I'm moving away from it. So I don't care
>>> as much as I did...
>>
>> Can you give conrete examples on what these obstacles are?
>
> Well, here are some:
> - in complex use cases the GUI logic, as Carsten's use case
> exemplifies, becomes spread all over the pipeline, and it becomes
> increasingly difficult to understand what happens where.
Could you explain how can you do the Carsten need easily with Wicket?
> - client/server communication with JSON makes it really easy to build
> Ajax apps, but is a pain to produce from Cocoon unless we directly
> send it from the controller, which actually makes Cocoon pipelines
> useless.
Why everything needs to go through pipelines?
> - Dojo widgets are a nice replacement for CForm's styling stylesheets,
> reduce the server load, and again make pipelines less useful.
Here is a trade off dojo reduce the server load but increase the client
load and bandwidth:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&w=2&r=1&s=dojo+fat&q=b
I am not telling dojo is bad, I like it, but I see here is a trade off.
Dojo usage is not a free lunch after all. ;-)
> - enhancing the CForms styling leads to a giant XSL (even if
> modularized) where every possible styling used in the application must
> be present.
It's not my experience. xslt allows us to just overwrite the required
pieces to enhance the styling.
> - since only CForms has Ajax integration, people are over-using it for
> presentation purposes (e.g. paginated repeater)
I agree with you, mixing binding with form definition is not good. We
want to keep it separated. However, I think it is a first implementation
wich show us a way to implement a paginated repeater after all it is not
released yet. It is a work in progress. Is not fair to blame to a first
draft implementation.
>
> Don't get me wrong: Cocoon is a killer for publication. But for
> webapps, other approaches, more Java-centric, are worth considering.
> My current choice is Wicket, which was just proposed for incubation.
I took a fast look at wicket and I can see an analogy to building a form
intensive application with XSP logicsheets. I already went this way and
I can say it is not not easy to maintain the code. I mean it is the same
code embedding concept with a new syntax sugar after all.
>
> Cocoon allows lots of non-Java people to build complicated stuff, and
> this is a major achievement. But I find it easier to write Java if
> you're fluent with it rather than finding workarounds in an
> XML-centric framework.
I feel myself fluent in Java and I still prefer find faster to write a
cform application using with cocoon. ;-)
Best Regards,
Antonio Gallardo.
Re: [CForms] Streaming out widget attributes?
Posted by Sylvain Wallez <sy...@apache.org>.
[resent -- seems to have been lost]
Reinhard Poetz wrote:
> Sylvain Wallez wrote:
>> I'm sorry to say that over time, I found Cocoon to be more an
>> obstactle for complex webapps pages (not talking about flow) than a
>> real help, and that's why I'm moving away from it. So I don't care as
>> much as I did...
>
> Can you give conrete examples on what these obstacles are?
Well, here are some:
- in complex use cases the GUI logic, as Carsten's use case exemplifies,
becomes spread all over the pipeline, and it becomes increasingly
difficult to understand what happens where.
- client/server communication with JSON makes it really easy to build
Ajax apps, but is a pain to produce from Cocoon unless we directly send
it from the controller, which actually makes Cocoon pipelines useless.
- Dojo widgets are a nice replacement for CForm's styling stylesheets,
reduce the server load, and again make pipelines less useful.
- enhancing the CForms styling leads to a giant XSL (even if
modularized) where every possible styling used in the application must
be present.
- since only CForms has Ajax integration, people are over-using it for
presentation purposes (e.g. paginated repeater)
Don't get me wrong: Cocoon is a killer for publication. But for webapps,
other approaches, more Java-centric, are worth considering. My current
choice is Wicket, which was just proposed for incubation.
Cocoon allows lots of non-Java people to build complicated stuff, and
this is a major achievement. But I find it easier to write Java if
you're fluent with it rather than finding workarounds in an XML-centric
framework.
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: [CForms] Streaming out widget attributes?
Posted by Reinhard Poetz <re...@apache.org>.
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
>> Sylvain Wallez wrote:
>>
>>> Yeah, but the point is about the "somewhere". Each element in a
>>> Cocoon pipeline is supposed to address a particular concern.
>>>
>>> Now over time, reasons emerge for everything to be useful everywhere,
>>> and we end up with a giant mix, where having different stages in a
>>> pipeline no more really make sense, and where each stage produces as
>>> much information as possible for the next one, for the occasional
>>> case where it may be useful, thus impacting the general performance
>>> just to handle these edge cases.
>>
>> Ok, in general you're right; but I'm wondering why for example we added
>> a special handling for suggestion lists which is rarely needed and seem
>> to refuse to add a more general approach which helps others as well.
>>
>
> Uh? Don't see what you mean here...
>
>> Streaming out the attributes of the field definition should in no way
>> change the performance as the attributes are empty in most cases anyway.
>>
>
> Ok, if others are ok with it, then so be it.
>
> I'm sorry to say that over time, I found Cocoon to be more an obstactle
> for complex webapps pages (not talking about flow) than a real help, and
> that's why I'm moving away from it. So I don't care as much as I did...
Can you give conrete examples on what these obstacles are?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Re: [CForms] Streaming out widget attributes?
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
>
>> Yeah, but the point is about the "somewhere". Each element in a Cocoon
>> pipeline is supposed to address a particular concern.
>>
>> Now over time, reasons emerge for everything to be useful everywhere,
>> and we end up with a giant mix, where having different stages in a
>> pipeline no more really make sense, and where each stage produces as
>> much information as possible for the next one, for the occasional case
>> where it may be useful, thus impacting the general performance just to
>> handle these edge cases.
>
> Ok, in general you're right; but I'm wondering why for example we added
> a special handling for suggestion lists which is rarely needed and seem
> to refuse to add a more general approach which helps others as well.
>
Uh? Don't see what you mean here...
> Streaming out the attributes of the field definition should in no way
> change the performance as the attributes are empty in most cases anyway.
>
Ok, if others are ok with it, then so be it.
I'm sorry to say that over time, I found Cocoon to be more an obstactle
for complex webapps pages (not talking about flow) than a real help, and
that's why I'm moving away from it. So I don't care as much as I did...
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: [CForms] Streaming out widget attributes?
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
>
> Yeah, but the point is about the "somewhere". Each element in a Cocoon
> pipeline is supposed to address a particular concern.
>
> Now over time, reasons emerge for everything to be useful everywhere,
> and we end up with a giant mix, where having different stages in a
> pipeline no more really make sense, and where each stage produces as
> much information as possible for the next one, for the occasional case
> where it may be useful, thus impacting the general performance just to
> handle these edge cases.
>
Ok, in general you're right; but I'm wondering why for example we added
a special handling for suggestion lists which is rarely needed and seem
to refuse to add a more general approach which helps others as well.
Streaming out the attributes of the field definition should in no way
change the performance as the attributes are empty in most cases anyway.
>
> Well, that looks like business logic to me, and can be handled by
> on-change events with Ajax.
I don't want to use ajax for this; i don't need a server request; I can
generate javascript which completly runs in the browser - which is much
faster and user friendly.
Carstem
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [CForms] Streaming out widget attributes?
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
> Sylvain Wallez wrote
>
>>> Yes, now I see two solutions for this: we could just stream out the
>>> attributes of
>>> the definition (which are strings) or if we need all attributes, stream
>>> out attributes which can be streamed.
>>> I would go for the first solution, anything against this?
>>>
>> Sounds hacky to me...
>
> Really? Why? You define something in the model which you want to access
> easily somewhere.
>
Yeah, but the point is about the "somewhere". Each element in a Cocoon
pipeline is supposed to address a particular concern.
Now over time, reasons emerge for everything to be useful everywhere,
and we end up with a giant mix, where having different stages in a
pipeline no more really make sense, and where each stage produces as
much information as possible for the next one, for the occasional case
where it may be useful, thus impacting the general performance just to
handle these edge cases.
>> Dumb question: why do you need these attributes in the XSL?
>>
>> Attributes were meant to allow additional information to be communicated
>> between the application logic and the various event handlers and
>> validators attached to widgets, whereas the XSLs are supposed to use the
>> styling information for their job.
>>
>
> Yes, but what if you need anything else apart from styling? For example
> "required" is
> passed from the model to the xsls.
> I want to pass on information like dependencies between fields, for
> example if field A has value 1, then field B is optional and if field A
> has value 2 field B is required. I need a generic mechanism here which
> just passes this information from the model to the xsls where I can
> generate some client javascript.
>
Well, that looks like business logic to me, and can be handled by
on-change events with Ajax.
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: [CForms] Streaming out widget attributes?
Posted by Carsten Ziegeler <cz...@apache.org>.
Bertrand Delacretaz wrote:
> On 8/3/06, Carsten Ziegeler <cz...@apache.org> wrote:
>
>> ...implementing client side validation for pre checking form
>> values is currently not possible as there is no way to pass on
>> validation information from the model to the stylesheets....
>
> Coming back to the original question, could you make the streaming out
> of widget attributes configurable, and turned off by default?
>
> In this way nothing changes for existing apps, clean separation of
> concerns is the default, yet people who know what they're doing can
> enable it.
>
Yes, sounds good to me. I'll have a look at how to get it working this way.
Thanks
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Re: [CForms] Streaming out widget attributes?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 8/3/06, Carsten Ziegeler <cz...@apache.org> wrote:
> ...implementing client side validation for pre checking form
> values is currently not possible as there is no way to pass on
> validation information from the model to the stylesheets....
Coming back to the original question, could you make the streaming out
of widget attributes configurable, and turned off by default?
In this way nothing changes for existing apps, clean separation of
concerns is the default, yet people who know what they're doing can
enable it.
-Bertrand
Re: [CForms] Streaming out widget attributes?
Posted by Carsten Ziegeler <cz...@apache.org>.
Antonio Gallardo wrote:
> IIRC, allowing to programmatically change the @required has been
> requested by some users. Perhaps, we should try to implement it. I mean
> in a similar way as currently we can programmatically change the @state
> of a widget.
It is already implemented :)
>
> Would this fill your need?
>
No :) Or, well, partially. I could solve it this way and already tried
it. But the ajax request updating the model and rerendering the
(partial) page is way to slow. So doing this completly on the client is
much faster/easier.
In addition, implementing client side validation for pre checking form
values is currently not possible as there is no way to pass on
validation information from the model to the stylesheets.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [CForms] Streaming out widget attributes?
Posted by Antonio Gallardo <ag...@agssa.net>.
Carsten Ziegeler escribió:
> Sylvain Wallez wrote
>
>>> Yes, now I see two solutions for this: we could just stream out the
>>> attributes of
>>> the definition (which are strings) or if we need all attributes, stream
>>> out attributes which can be streamed.
>>> I would go for the first solution, anything against this?
>>>
>>>
>> Sounds hacky to me...
>>
>>
> Really? Why? You define something in the model which you want to access
> easily somewhere.
>
>
>> Dumb question: why do you need these attributes in the XSL?
>>
>> Attributes were meant to allow additional information to be communicated
>> between the application logic and the various event handlers and
>> validators attached to widgets, whereas the XSLs are supposed to use the
>> styling information for their job.
>>
> Yes, but what if you need anything else apart from styling? For example
> "required" is
> passed from the model to the xsls.
> I want to pass on information like dependencies between fields, for
> example if field A has value 1, then field B is optional and if field A
> has value 2 field B is required. I need a generic mechanism here which
> just passes this information from the model to the xsls where I can
> generate some client javascript.
>
IIRC, allowing to programmatically change the @required has been
requested by some users. Perhaps, we should try to implement it. I mean
in a similar way as currently we can programmatically change the @state
of a widget.
Would this fill your need?
Best Regards,
Antonio Gallardo.
Re: [CForms] Streaming out widget attributes?
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote
>> Yes, now I see two solutions for this: we could just stream out the
>> attributes of
>> the definition (which are strings) or if we need all attributes, stream
>> out attributes which can be streamed.
>> I would go for the first solution, anything against this?
>>
>
> Sounds hacky to me...
>
Really? Why? You define something in the model which you want to access
easily somewhere.
> Dumb question: why do you need these attributes in the XSL?
>
> Attributes were meant to allow additional information to be communicated
> between the application logic and the various event handlers and
> validators attached to widgets, whereas the XSLs are supposed to use the
> styling information for their job.
Yes, but what if you need anything else apart from styling? For example
"required" is
passed from the model to the xsls.
I want to pass on information like dependencies between fields, for
example if field A has value 1, then field B is optional and if field A
has value 2 field B is required. I need a generic mechanism here which
just passes this information from the model to the xsls where I can
generate some client javascript.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [CForms] Streaming out widget attributes?
Posted by Antonio Gallardo <ag...@agssa.net>.
Sylvain Wallez escribió:
> Carsten Ziegeler wrote:
>> Sylvain Wallez schrieb:
>>
>>> Carsten Ziegeler wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm currently looking into a way of getting information for a
>>>> widget in
>>>> my template that has been defined in the model. But it seems to me
>>>> that
>>>> this is not possible right now.
>>>> Is anyone against streaming out all attributes of a widget in the
>>>> generateSaxFragment() method? As attributes are not used frequently I
>>>> think this shouldn't create problems.
>>>>
>>> This *will* create problems, as attributes can be of any type, and
>>> not just Strings (although only Strings can be specified in the
>>> widget's definition).
>>>
>>
>> Yes, now I see two solutions for this: we could just stream out the
>> attributes of
>> the definition (which are strings) or if we need all attributes, stream
>> out attributes which can be streamed.
>> I would go for the first solution, anything against this?
>>
>
> Sounds hacky to me...
Same here. Also, seems to me it should have a non desired performance
impact in form rendering.
Best Regards,
Antonio Gallardo.
Re: [CForms] Streaming out widget attributes?
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
> Sylvain Wallez schrieb:
>
>> Carsten Ziegeler wrote:
>>
>>> Hi,
>>>
>>> I'm currently looking into a way of getting information for a widget in
>>> my template that has been defined in the model. But it seems to me that
>>> this is not possible right now.
>>> Is anyone against streaming out all attributes of a widget in the
>>> generateSaxFragment() method? As attributes are not used frequently I
>>> think this shouldn't create problems.
>>>
>> This *will* create problems, as attributes can be of any type, and not
>> just Strings (although only Strings can be specified in the widget's
>> definition).
>>
>
> Yes, now I see two solutions for this: we could just stream out the
> attributes of
> the definition (which are strings) or if we need all attributes, stream
> out attributes which can be streamed.
> I would go for the first solution, anything against this?
>
Sounds hacky to me...
>> Now if you're using JXTemplate, you can directly access attribute values
>> with ${widget.getAttribute('foo')}.
>>
>
> Yes, I know but I can't *directly* access the attributes in an xsl
> stylesheet. And unfortunately it's not possible to overwrite the
> jxmacros and extend the streaming mechanism there.
>
Dumb question: why do you need these attributes in the XSL?
Attributes were meant to allow additional information to be communicated
between the application logic and the various event handlers and
validators attached to widgets, whereas the XSLs are supposed to use the
styling information for their job.
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: [CForms] Streaming out widget attributes?
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez schrieb:
> Carsten Ziegeler wrote:
>> Hi,
>>
>> I'm currently looking into a way of getting information for a widget in
>> my template that has been defined in the model. But it seems to me that
>> this is not possible right now.
>> Is anyone against streaming out all attributes of a widget in the
>> generateSaxFragment() method? As attributes are not used frequently I
>> think this shouldn't create problems.
>>
>
> This *will* create problems, as attributes can be of any type, and not
> just Strings (although only Strings can be specified in the widget's
> definition).
Yes, now I see two solutions for this: we could just stream out the
attributes of
the definition (which are strings) or if we need all attributes, stream
out attributes which can be streamed.
I would go for the first solution, anything against this?
> Now if you're using JXTemplate, you can directly access attribute values
> with ${widget.getAttribute('foo')}.
Yes, I know but I can't *directly* access the attributes in an xsl
stylesheet. And unfortunately it's not possible to overwrite the
jxmacros and extend the streaming mechanism there.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [CForms] Streaming out widget attributes?
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
> Hi,
>
> I'm currently looking into a way of getting information for a widget in
> my template that has been defined in the model. But it seems to me that
> this is not possible right now.
> Is anyone against streaming out all attributes of a widget in the
> generateSaxFragment() method? As attributes are not used frequently I
> think this shouldn't create problems.
>
This *will* create problems, as attributes can be of any type, and not
just Strings (although only Strings can be specified in the widget's
definition).
Now if you're using JXTemplate, you can directly access attribute values
with ${widget.getAttribute('foo')}.
Sylvain
--
Sylvain Wallez - http://bluxte.net