[Zope3-Users] z3c.formjs - global js-variables and form-content in scripts
paulcarduner at gmail.com
Thu Sep 18 02:26:28 EDT 2008
On Wed, Sep 17, 2008 at 4:48 PM, garz <garz at gmx.net> wrote:
> i'm working with z3c.formjs and there are three questions that arose.
> 1.) defining global variables
> i'd like to define some global variables that i can refer to in the
> functions that i want to define with the jsfunction-package. for example a
> global counter that counts something. is there any possibility to do so?
include style sheets and other resources: either by placing said
objects and the viewlet manager pattern. As long as your global
all rendered jsfunctions.
> 2.) form-content in jsfunctions-scripts
> i want to define a jsfunction that returns a rendered widget. this widget is
> an information that the particular instance of a form has. so i need to
> somehow access that form to get that widget. as far as i can see this there
> is no possibility to do this with jfsunction-package, since the functions
> defined with it are static and they arent given any useful parameter-values
> when called.
form. I'm not sure I completely understand your use case. When you
say form and widget, are you referring to the form and widget as they
are represented on the server side or as they are rendered on the
client's web page?
> so i looked at jsevent and jsaction but the problem there is they dont know
> the source form neither. they know the calling request, but since im working
> with subforms, i need to know the exact form where the executed handler is
> coming from. neither the request nor the jssubscriptions know about the
> so it isnt meant to weave form-specific data into the js-script. so what is
> the solution to this? i cant see it.
Again I'm not sure if you are talking about server or client. From
the server perspective, if you have
return u"alert('the fields in this form are %s');" % [w.id for w in
function so it is not dynamic from the client perspective.
> 3.) jssubscriptions-renderer
> why are those renderers only in the testing-package? arent they good enough?
> or is this usually done another way?
There is JQuerySubscriptionRenderer in jqueryrenderer.py. It looks
just like the one in testing because jquery is the reference
> my goal is to write a general sequence-form, that can display a sequence
> consisting of an arbitrary widget. it should provide delete-buttons for
> every element. in add-forms, the functionality of these should be realized
> submit but with ajax.
This particular use case I think is too high level for a package like
formjs, but would certainly be a great addition as an example in
formjsdemo. It seems quite similar to the tree editor demo in
> since i dont think that that there is a solution to this need, i think i
> will have to adjust formjs. i would like to make that clean, means i dont
> want to do a "hacky" formjs-adaption. maybe this usecase is already known
> and there is interest in evolving formjs? maybe through new packages? maybe
> through rewrites?
Extensions to formjs for supporting these types of CRUD use cases are
certainly welcome. Feel free to start hacking on a branch.
More information about the Zope3-users