plone.autoform: Widget traversal over WidgetsView
jones
Today I implemented plone.formwidget.multifile (a widget for List /
NamedFile combination with asynchronous upload). Now I'm using the
default @@download view of plone.formwidget.namedfile, so I have a URL
like this one:
...myobj/@@edit/++widget++manyfiles/3/@@download
Now that's working pretty well on the @@edit view, but it does not
work on the @@view view (default dexterity view).
I did some investigations on that and I may have figured out what the
problem is:
The z3c.form widget traversal adapter (z3c.form.traversal) does
something like this:
form = self._prepareForm()
form.update()
form.widgets ...
Now the view (in plone.autoform.view.WidgetsView) does override the
update method with:
def update(self):
pass
So when using the WidgetsVIew the widgets only get loaded when calling
it (__call__) but the traversal adapter does not call it, so no
widgets are there.
It results in a NoneType error.
Now what's the reason that the update method does not update the
widgets there? Can we change that?
Cheers
Jonas
Martin Aspeli
I suspect it was an optimisation, but it sounds like maybe a bad choice.
Can you try to change it and see if anything (tests, TTW) breaks? If
not, I suggest you commit it.
Martin
Baumann Jonas
The tests didn't run when just renaming _update() to update(), so I changed
update() to call self.updateFieldsFromSchemata() and self.updateWidgets(),
which solves the problem.
I added a Test too.
Cheers
Jonas
> --
> You received this message because you are subscribed to the Google Groups "Dexterity development" group.
> To post to this group, send email to dexterity-...@googlegroups.com.
> To unsubscribe from this group, send email to dexterity-develo...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/dexterity-development?hl=en.
>
Martin Aspeli
> Hey
>
> The tests didn't run when just renaming _update() to update(), so I changed
> update() to call self.updateFieldsFromSchemata() and self.updateWidgets(),
> which solves the problem.
> I added a Test too.
Cool! Can you please also test a few types TTW just to make sure there
are no weird side effects? Then feel free to commit.
Martin
Baumann Jonas
I did some more testing and I discovered that widget traversal still doesn't
work for the display view.
In plone.z3cform.traversal (its there, not in z3c.form like I said before) there
are two traversal adapters register:
WrapperWidgetTraversal, adapts(IFormWrapper, IBrowserRequest)
FormWidgetTraversal, adapts(IForm, IBrowserRequest)
The first one is for the form-view and just returns the form, then the second one
is called (and there the form.widgets is required, which I fixed before).
The problem is now that @@view does not seem to provide IFormWrapper
but the @@edit view does. That's why it does not work yet.
Actually I see two solutions for that problem:
1. Let WidgetsView provide IFormWrapper, which do not prefer since it could
have side effects...
2. Add a third traversal adapter registered on IWidgetsView which does the
same like the WrapperWidgetTraversal adapter does - just return the form.
I think that should work.
What do you think?
By the way I could not find any issues when testing manually TTW with my
changes on the WidgetsView, so I think my changes work :-)
Cheers
Jonas
Martin Aspeli
> Hi Martin,
>
> I did some more testing and I discovered that widget traversal still doesn't
> work for the display view.
>
> In plone.z3cform.traversal (its there, not in z3c.form like I said before) there
> are two traversal adapters register:
>
> WrapperWidgetTraversal, adapts(IFormWrapper, IBrowserRequest)
> FormWidgetTraversal, adapts(IForm, IBrowserRequest)
>
> The first one is for the form-view and just returns the form, then the second one
> is called (and there the form.widgets is required, which I fixed before).
>
> The problem is now that @@view does not seem to provide IFormWrapper
> but the @@edit view does. That's why it does not work yet.
Note that form wrappers are semi-deprecated. They're necessary in
Plone < 4, but stupid and should go away.
> Actually I see two solutions for that problem:
>
> 1. Let WidgetsView provide IFormWrapper, which do not prefer since it could
> have side effects...
-1 -- this is not what this interface is meant to convey.
> 2. Add a third traversal adapter registered on IWidgetsView which does the
> same like the WrapperWidgetTraversal adapter does - just return the form.
> I think that should work.
I'm not quite understanding why this is necessary. Can you explain more fully?
Another traversal adapter shouldn't live in plone.z3cform at least,
since IWidgetsView is a feature of plone.autoform. A traversal adapter
in plone.autoform could be OK, though instinctively it doesn't feel
like it ought to be necessary.
Martin
Baumann Jonas
Am 29.08.2010 um 16:07 schrieb Martin Aspeli:
> On 29 August 2010 23:03, Baumann Jonas <tsch...@gmail.com> wrote:
>> Hi Martin,
>>
>> I did some more testing and I discovered that widget traversal still doesn't
>> work for the display view.
>>
>> In plone.z3cform.traversal (its there, not in z3c.form like I said before) there
>> are two traversal adapters register:
>>
>> WrapperWidgetTraversal, adapts(IFormWrapper, IBrowserRequest)
>> FormWidgetTraversal, adapts(IForm, IBrowserRequest)
>>
>> The first one is for the form-view and just returns the form, then the second one
>> is called (and there the form.widgets is required, which I fixed before).
>>
>> The problem is now that @@view does not seem to provide IFormWrapper
>> but the @@edit view does. That's why it does not work yet.
>
> Note that form wrappers are semi-deprecated. They're necessary in
> Plone < 4, but stupid and should go away.
>
>> Actually I see two solutions for that problem:
>>
>> 1. Let WidgetsView provide IFormWrapper, which do not prefer since it could
>> have side effects...
>
> -1 -- this is not what this interface is meant to convey.
>
>> 2. Add a third traversal adapter registered on IWidgetsView which does the
>> same like the WrapperWidgetTraversal adapter does - just return the form.
>> I think that should work.
>
> I'm not quite understanding why this is necessary. Can you explain more fully?
The Problem is, that there is no traversal adapter registered for the WidgetsView.
There is one for @@edit (on IForm), but the WidgetsView does not have IForm.
The result is that impossible to do something like …/@@view/++widget++myfield
I'm writing the plone.formwidget.multifile which allows to have a List of NamedFiles
in the schema. On the edit view I'm having a download link which points to the
download-view of plone.formwidget.namedfile, so need to traverse over the
widget (…/@@edit/++widget++files/2/@@download). That's working for the edit
view but not for the display view.
Maybe I should just not do it that way but create a @@download-multifle view
for "*" which is not based on traversal. But I think it would be nice to be able to
traverse on the display view too.
Jonas
>
> Another traversal adapter shouldn't live in plone.z3cform at least,
> since IWidgetsView is a feature of plone.autoform. A traversal adapter
> in plone.autoform could be OK, though instinctively it doesn't feel
> like it ought to be necessary.
>
> Martin
>
JMehring
remember, you don't include the ++widget++... in the view templates.
I don't have the code handy, but can post an example tomorrow.
Jason
JMehring
plone.autoform.view.WidgetsView update() since in the view it will
take the attribute value from the context. You should not need to
traverse the ++widget++FIELD directly in that mode since you are not
changing the values at that point.
Jason
Baumann Jonas
>> remember, you don't include the ++widget++... in the view templates.
>> I don't have the code handy, but can post an example tomorrow.
>
There are two download views, one in plone.namedfile (Field, registered
for Interface) and one in plone.formwidget.namedfile (Widget, registered
for INamedFileWidget (which uses ++widget++).
If I'm now creating another download view for my widget have to register
it on Interface too, and name it something like multifile-download, right?
Because when I'm naming it download too it will conflict with the download
view of plone.namedfile. That's why I thought it would be nice to register
it on the widget.
> Forgot to mention that there should be no need to change
> plone.autoform.view.WidgetsView update() since in the view it will
> take the attribute value from the context. You should not need to
> traverse the ++widget++FIELD directly in that mode since you are not
> changing the values at that point.
So should I revert my changes in plone.autoform and solve my problem
by prefixing the view name? I just think it's not very beautiful to register
my view for Interface ...
Jonas
JMehring
On Aug 31, 6:36 am, Baumann Jonas <tscho...@gmail.com> wrote:
> >> I implemented list for NamedFile a few months back and from what I can
> >> remember, you don't include the ++widget++... in the view templates.
> >> I don't have the code handy, but can post an example tomorrow.
>
> There are two download views, one in plone.namedfile (Field, registered
> for Interface) and one in plone.formwidget.namedfile (Widget, registered
> for INamedFileWidget (which uses ++widget++).
>
> If I'm now creating another download view for my widget have to register
> it on Interface too, and name it something like multifile-download, right?
> Because when I'm naming it download too it will conflict with the download
> view of plone.namedfile. That's why I thought it would be nice to register
> it on the widget.
>
> > Forgot to mention that there should be no need to change
> > plone.autoform.view.WidgetsView update() since in the view it will
> > take the attribute value from the context. You should not need to
> > traverse the ++widget++FIELD directly in that mode since you are not
> > changing the values at that point.
>
> So should I revert my changes in plone.autoform and solve my problem
> by prefixing the view name? I just think it's not very beautiful to register
> my view for Interface ...
performance hit, although it would be nice to be able to traverse a +
+widget++ in view mode. I am new to the plone front, so I am not the
best person to suggest which route to take even though I do understand
why you are leaning towards this approach.
Jason
JMehring
branch for dexterity content types. Once you are finished with your
implementation I would like to make this package compatible with it
(create a branch)
Basically I would yank out your draft support and in order to use this
widget, the user would be need to set the
plone.app.interface.IDraftable behavior; the IDraftable behavior
should be able to handle all your draft needs automatically (when the
user submits the form, a copy of your request.form.value will be
copied into the request.form). I did not need to change much in
plone.formwidget.namedfile in order for it to work; mostly just things
relating to ignoreContext.
The only problem doing this would be that if a user does not include
the IDraftable behavior the widget would not work... So it will be
interesting to figure out a solution to solve this (maybe if the
behavior does not exist; then add it automatically by marking the
content object?)
Is that okay with you?
Jason
Baumann Jonas
a flash plugin for uploading the files. This makes it possible to select
multiple files at once in the (OS depending) file selection dialog, and
the files are uploaded directly after selecting them. So there is no file
in the submitted form.
The flash plugin sends the files to a special view which stores the files
in the plone.app.drafts storage (since the object may not exist yet). The
z3cform converter gets the files then back from the storage when the
form is submitted.
So I think the concept of plone.app.drafts does not work (or does not
replace what I did) - or do I understand the drafts stuff wrong?
The widget is used in deco for the attachment tile (plone.app.standardtiles).
These tiles do not use behaviors, so there should be a way to use the
widget without behaviors.
I think plone.app.drafts support is planned for tiles too, so drafts should
not depend to much on behaviors...
Cheers
Jonas
JMehring
> Currently the widget is based on jQuery uploadify, which includes
> a flash plugin for uploading the files. This makes it possible to select
> multiple files at once in the (OS depending) file selection dialog, and
> the files are uploaded directly after selecting them. So there is no file
> in the submitted form.
>
> The flash plugin sends the files to a special view which stores the files
> in the plone.app.drafts storage (since the object may not exist yet). The
> z3cform converter gets the files then back from the storage when the
> form is submitted.
>
> So I think the concept of plone.app.drafts does not work (or does not
> replace what I did) - or do I understand the drafts stuff wrong?
that is widget related from in a draft from request.form and
repopulates it each time a new request is initiated. This works for
objects that have not yet been created as well (++add++ form).
Therefore your 'Filedata' field will be stored in the draft and when
the user clicks submit, that field will be re-populated into the
form.request and therefore available to the widget to render on
submit. This should also take care of the limitation of not being
able to use this widget with HTTP basic authentication. (There is
also an option IDraftPreview behavior to preview a page before it is
submitted).
If we leave your package as is I will need to test how it behaves with
IDraftable behavior enabled, since the 'Filedata' field will still be
stored in the request.form once the form is submitted (so it may try
to add it to your draft again?)
I currently have some unreleased code (cause its not complete) to
autopreview images (without reloading complete page) in the browser
using ajax. Basically it just sends a ajax request of image, and it
gets stored in draft automatically; no special view required; then
when form is submitted; the image field is repopulated back into
request so it 'looks' like it was actually submitted with form.
I have only briefly looked at your package code but would think I
would not need to modify much to have it work with the IDraftable
behavior ( probably mostly just need to modify extract(), and
eliminating need for special view ).
I am horrible at explaining things :) maybe I need better explanation
of what IDraftable behavior can do!
>
> The widget is used in deco for the attachment tile (plone.app.standardtiles).
> These tiles do not use behaviors, so there should be a way to use the
> widget without behaviors.
> I think plone.app.drafts support is planned for tiles too, so drafts should
> not depend to much on behaviors...
opt-in behavior by design to allow integrators / developers the option
to allow draft support or not. Since it is an opt-in behavior, I we
would either need to make sure people using this widget enabled it; or
enable it automatically since it would be required. Personally I
enable it for everything :)
Jason
Baumann Jonas
Am 31.08.2010 um 20:19 schrieb JMehring:
> This should also take care of the limitation of not being
> able to use this widget with HTTP basic authentication.
The HTTP basic authentication is not supported because the uploadify
flash plugin does not support it (or I don't know how to pass the credentials
of the authenticated user to the plugin). I'm just passing the __ac as
parameter to the flash plugin and move it to the cookies when the
request arrives (while traversing).
> I have only briefly looked at your package code but would think I
> would not need to modify much to have it work with the IDraftable
> behavior ( probably mostly just need to modify extract(), and
> eliminating need for special view ).
Feel free to change what you need to change. The package is not complete
yet anyway - there are some parts I wanted to make better, I want to make
a non-flash fallback and to write some tests...
Jonas
JMehring
> Feel free to change what you need to change. The package is not complete
> yet anyway - there are some parts I wanted to make better, I want to make
> a non-flash fallback and to write some tests...
zc3.form.widgets I need to patch as well. I think you have done a
good job so far on what you have complete.
I wouldn't mind implementing image preview as well with this module
and a non-flash fallback sound good too.
If I can get the widget working directly with the drafts behavior; I
will upload it as a separate branch for your review; otherwise I
wouldn't mind helping on writing an image preview part for this. I'm
not sure if uploadify will support that or not.
Take care,
Jason
Baumann Jonas
Am 01.09.2010 um 09:08 schrieb JMehring:
>
>> Feel free to change what you need to change. The package is not complete
>> yet anyway - there are some parts I wanted to make better, I want to make
>> a non-flash fallback and to write some tests...
>
> Ok, thanks. I started work on it last night. I found a small bug in
> zc3.form.widgets I need to patch as well. I think you have done a
> good job so far on what you have complete.
Thanks :)
> I wouldn't mind implementing image preview as well with this module
> and a non-flash fallback sound good too.
>
> If I can get the widget working directly with the drafts behavior; I
> will upload it as a separate branch for your review; otherwise I
> wouldn't mind helping on writing an image preview part for this. I'm
> not sure if uploadify will support that or not.
That would be cool. I also thought about a image part.
At the moment the html for the just uploaded file is generated in the JS, but
I would like to get it from the file_template.pt, but we have to look how we can
access it.
Once this is changed it will be quiet easy to preview the image directly after
uploading..
Cheers,
Jonas
> Take care,
JMehring
I have uploaded the branch which now works with dexterity drafts
behavior to store the draft. Currently you need to have the behavior
enabled but I will change this so the widget will work if the behavior
is enabled or not.
To use it you will need to extend the drafts.cfg located at
https://svn.plone.org/svn/plone/plone.dexterity/buildouts/drafts.cfg.
I use the buildout configuration files from that directory. draft.cfg
includes 6-7 branches in development for the drafts code. To use
dexterity drafts; check out the drafts.txt in
https://svn.plone.org/svn/plone/plone.app.dexterity/branches/jmehring-drafts/plone/app/dexterity/behaviors/drafts.txt.
This is work in progress, but adding files (and images) works. I have
not yet implemented remove.
Changes so far
----------------------
- Removed old draft temporary file) code and converter and references
to them
- Implemented multifile to use plone drafts behavior to store its
files automatically ('knda' hehe)
- Implemented the 'BROWSE' button to save multiple files
- send JSON response to jQuery.
- updates html with value from .pt template; currently from
namedfile/namedimage. Will change to a better looking template
- sends back filename
- sends back counter and updates HTML value
- sends back status of 'error' or success
Seems like display is not updating correctly in browser when adding
from ++add++ form (progress bar shows 100% complete, but does not
update). Need to fix javascript code
Thing I can think of to do
------------------------------------
1) ajax fallback
2) allow multifile to function without 'plone.app.drafts.IDraftable'
behavior set
3) implement pre-check before sending file to make sure has not
already been sent before
4) implement remove action
5) send back a nice template to browser
6) auto image preview (no longer limited to namedfile)
7) many more tests :) maybe some with windmill or selenium
I can work on this project this week and implement as many of the
above as possible. I don't want to duplicate any of your efforts so
if you are working on some of the above; let me know. If you can
think of anything else to add; ditto!
Jason
PS If you need help installing the drafts behaviors, etc; just let me
know so I can provide examples
PPS There is a bug in widget.py around line 309 that is incorrectly
getting the context (gets it differently for plone 3 / 4). I don't
have time to fix it tonight, so I made it work with Plone 4 for now.
uncomment out other line to work with Plone 3 if that what you are
using until I can figure out a way to correct grab the context. (or
maybe you know how)
Currently add is working
JMehring
Well looks like I need to re-factor the plone.app.dexterity.drafts
code into its own package to allow formlib widgets to be able to use
it, otherwise the widget would need to depend on dexterity being
installed. I only noticed this when I needed to provide an import for
an interface in multifile widget :)
Shouldn't take too long to do since there is not much ties to
dexterity except the opt-in behaviors.
The benefit is that formlib can take advantage of drafts being created
automatically as well.
Jason
Martin Aspeli
JMehring
On Sep 8, 3:19 am, Martin Aspeli <optil...@gmail.com> wrote:
Jason
Baumann Jonas
You did a lot of changes and improvements, I really appreciate that. I
tried to get the widget run again on your branch with deco, but that didn't
work yet. I think that's because I didn't install the drafts stuff for the type,
like you mentioned above.
It would be really grate if the widget would work with drafts but also with
deco (without drafts).
You changed the way of getting the form in the receiver view and the flash
is now sending the name of the form to the view. I'm not sure if this approach
will work with deco since the URLs of the add / edit forms of tiles may be
different to normal dexterity add / edit form URLs. I didn't yet investigate on
that but it seems that the view cannot get the form properly
(in widget.py, "form = form.form_instance").
I checked it yesterday and now I just noticed that you already changed that,
so I'll keep testing it..
> Thing I can think of to do
> ------------------------------------
> 1) ajax fallback
> 2) allow multifile to function without 'plone.app.drafts.IDraftable'
> behavior set
> 3) implement pre-check before sending file to make sure has not
> already been sent before
> 4) implement remove action
> 5) send back a nice template to browser
> 6) auto image preview (no longer limited to namedfile)
> 7) many more tests :) maybe some with windmill or selenium
That would be really great! :)
>
> I can work on this project this week and implement as many of the
> above as possible. I don't want to duplicate any of your efforts so
> if you are working on some of the above; let me know. If you can
> think of anything else to add; ditto!
I'm currently quiet busy and I'm not able to spend that much time, so
you can just modify the stuff you need to change and I'll keep an eye
on your changes ;)
>
> Jason
>
> PS If you need help installing the drafts behaviors, etc; just let me
> know so I can provide examples
>
> PPS There is a bug in widget.py around line 309 that is incorrectly
> getting the context (gets it differently for plone 3 / 4). I don't
> have time to fix it tonight, so I made it work with Plone 4 for now.
> uncomment out other line to work with Plone 3 if that what you are
> using until I can figure out a way to correct grab the context. (or
> maybe you know how)
>
>
> Currently add is working
>
>
Cheers
Jonas
JMehring
> deco (without drafts).
> You changed the way of getting the form in the receiver view and the flash
> is now sending the name of the form to the view. I'm not sure if this approach
> will work with deco since the URLs of the add / edit forms of tiles may be
> different to normal dexterity add / edit form URLs. I didn't yet investigate on
> that but it seems that the view cannot get the form properly
> (in widget.py, "form = form.form_instance").
deco buildout.cfg, but am having problems getting it to run with that
configuration; seems the deco example crashes on me; even crashes zope
if I try installing it at point of creating a new plone site. I gotta
debug this further...
If anyone listening can get me an invite to the google groups for deco
that may be a good place to me to research deco to make sure form
drafts works with it too :)
Jason
Baumann Jonas
Am 08.09.2010 um 17:52 schrieb JMehring:
>> It would be really grate if the widget would work with drafts but also with
>> deco (without drafts).
>> You changed the way of getting the form in the receiver view and the flash
>> is now sending the name of the form to the view. I'm not sure if this approach
>> will work with deco since the URLs of the add / edit forms of tiles may be
>> different to normal dexterity add / edit form URLs. I didn't yet investigate on
>> that but it seems that the view cannot get the form properly
>> (in widget.py, "form = form.form_instance").
>
> I will test with deco as well then. I tried installing deco from the
> deco buildout.cfg, but am having problems getting it to run with that
> configuration; seems the deco example crashes on me; even crashes zope
> if I try installing it at point of creating a new plone site. I gotta
> debug this further...
The examples does not work at the moment, I also noticed that. The registry
layout was refactored at the living statues sprint and I think this package got
lost.
But anyway: it is not required. Just install the Page, it will create a Page
dexterity content type with deco stuff - I think that should work
Jonas
> If anyone listening can get me an invite to the google groups for deco
> that may be a good place to me to research deco to make sure form
> drafts works with it too :)
>
> Jason
>
JMehring
version. Still no features yet, but it works with my newly refactored
plone.app.z3cformdrafts package. (Don't mind the code; its a mess
right now since I just got it to work with new drafts code and don't
want to delete stuff until I implement all the features :)
Now widgets can simply include the plone.app.z3cformdrafts package and
implement plone.app.drafts.interface.IDraftable and a draft will
automatically be provided for the wigdet, regardless if a behavior is
enabled or not. This should work with plain z3cform as well as
dexterity forms as well now.
I hope to add the ajax features and cleanup and complete the widget
this week.
> >> It would be really grate if the widget would work with drafts but also with
> >> deco (without drafts).
> >> You changed the way of getting the form in the receiver view and the flash
> >> is now sending the name of the form to the view. I'm not sure if this approach
> >> will work with deco since the URLs of the add / edit forms of tiles may be
> >> different to normal dexterity add / edit form URLs. I didn't yet investigate on
> >> that but it seems that the view cannot get the form properly
> >> (in widget.py, "form = form.form_instance").
> > I will test with deco as well then. I tried installing deco from the
> > deco buildout.cfg, but am having problems getting it to run with that
> > configuration; seems the deco example crashes on me; even crashes zope
> > if I try installing it at point of creating a new plone site. I gotta
> > debug this further...
>
> The examples does not work at the moment, I also noticed that. The registry
> layout was refactored at the living statues sprint and I think this package got
> lost.
>
> But anyway: it is not required. Just install the Page, it will create a Page
> dexterity content type with deco stuff - I think that should work
specific deco content type you wanted me to test against? Do you know
of anything that is currently using the plone.formwidget.multifile so
I can just plug in my branch to confirm it still works?
Jason
Baumann Jonas
Am 28.09.2010 um 00:19 schrieb JMehring:
> Just to let you know I am still working on this; I just uploaded a new
> version. Still no features yet, but it works with my newly refactored
> plone.app.z3cformdrafts package. (Don't mind the code; its a mess
> right now since I just got it to work with new drafts code and don't
> want to delete stuff until I implement all the features :)
>
> Now widgets can simply include the plone.app.z3cformdrafts package and
> implement plone.app.drafts.interface.IDraftable and a draft will
> automatically be provided for the wigdet, regardless if a behavior is
> enabled or not. This should work with plain z3cform as well as
> dexterity forms as well now.
>
> I hope to add the ajax features and cleanup and complete the widget
> this week.
Cool, thanks :)
>
>>>> It would be really grate if the widget would work with drafts but also with
>>>> deco (without drafts).
>>>> You changed the way of getting the form in the receiver view and the flash
>>>> is now sending the name of the form to the view. I'm not sure if this approach
>>>> will work with deco since the URLs of the add / edit forms of tiles may be
>>>> different to normal dexterity add / edit form URLs. I didn't yet investigate on
>>>> that but it seems that the view cannot get the form properly
>>>> (in widget.py, "form = form.form_instance").
>
> I still have not tested with deco, but will be sure it works.
>
>>> I will test with deco as well then. I tried installing deco from the
>>> deco buildout.cfg, but am having problems getting it to run with that
>>> configuration; seems the deco example crashes on me; even crashes zope
>>> if I try installing it at point of creating a new plone site. I gotta
>>> debug this further...
>>
>> The examples does not work at the moment, I also noticed that. The registry
>> layout was refactored at the living statues sprint and I think this package got
>> lost.
>>
>> But anyway: it is not required. Just install the Page, it will create a Page
>> dexterity content type with deco stuff - I think that should work
>
> Since I have not used deco much, I was wondering if there was a
> specific deco content type you wanted me to test against? Do you know
> of anything that is currently using the plone.formwidget.multifile so
> I can just plug in my branch to confirm it still works?
At the moment the primary content type to use is the deco page (p.a.page). When
editing / creating a page you can add a "attachment tile" (p.a.standardtiles)
which uses the multifile. That's the only place where it's used at the moment, I think.
BTW the buildout for deco was moved:
http://svn.plone.org/svn/plone/plone.app.deco/buildouts/dev/
Cheers,
Jonas
JMehring
with no delete and unfinished templates, etc (and its still a real
mess, but I need to back it up in repo; just incase hehe).
I based it on the http://valums.com/ajax-upload/ and 'borrowed' code
from collective.quickupload.
Here are the features:
This plugin uses XHR for uploading multiple files with progress-
bar in FF3.6+, Safari4+, Chrome and falls back to hidden iframe based
upload in other browsers, providing good user experience everywhere.
* multiple file select in FF, Chrome, Safari
* progress-bar in FF, Chrome6+, Safari
* drag-and-drop file select in FF, Chrome
* stylable via CSS
* uploads are cancellable
* no external dependencies
* doesn't use Flash
* fully working with https
* keyboard support in FF, Chrome, Safari
* supports IE6-8, Firefox 3-4beta, Safari4-5, Chrome, Opera
* Drag-and-drop is supported in FF, Chrome. Progress-bar is
supported in FF3.6+, Chrome6+, Safari4+
The plugin will fall back to hidden iframe in IE8, and other browsers
that do not support XHR. That means they can only select one file at
a time (need to click BROWSE for each file upload).
Of course I have the flash uploadify already working too which works
with all browsers, but does not http authenicate.
So, I wonder what the default behaviour of this widget should be. I
guess we can make it developer selectable.
Current behavior would either be:
1) Use XHR and fall back to iframe --or--
2) Use flash
Are these two options acceptable, or should we create another option:
3) Use XHR and fall back to flash, and possibly fall back further to
iframe if flash is not available or http auth is required?
Third option will take some time, but should be doable (if I can find
a way in widget or javascript to know if we will be needing to http
auth)
Jason
JMehring
I have the plone.formwidget.multifile widget branch working with
z3cformdrafts and dexterity but have a problem with deco tiles right
now. The draft portion works but the tile is wrapping my JSON
response in HTML like this:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://
www.w3.org/TR/REC-html40/loose.dtd">
<html><body>
<p>{"counter": 6, "html": "\n </p>
<li class='\"multifile-file\"'>\n <img src="%5C%22http://localhost:
50080/Plone/image.png%5C%22" alt='\"\"'>\n <a href="%5C%22http://
localhost:50080/Plone/@@add-tile/++widget++files/
ON20070820102835590_20099901393850284-display.jpg/@@download/
ON20070820102835590_20099901393850284-display.jpg%5C%22"><span
class='\"filename\"'>ON20070820102835590_20099901393850284-
display.jpg</span>\n </a>\n <span class='\"discreet\"'>\n
—\n 18 KB\n </span>\n \n <span class='\"discreet
\"'>\n —\n <a href="%5C%22%5C%22"
class='\"multifile-delete\"'>delete</a>\n </span>\n \n </li>\n
\n", "success": true, "filename":
"ON20070820102835590_20099901393850284-display.jpg"}</body></html>
even though I specifically set the response to this:
response.setHeader('Expires', 'Sat, 1 Jan 2000 00:00:00 GMT')
response.setHeader('Cache-control', 'no-cache')
response.setHeader('Content-Type', 'text/html; charset=utf-8')
Since the response is being wrapped in XHTML, it won't add the server
side template html code to the list (again since the return end up not
being valid JSON). If I can get that worked out; the widget will work
with deco (plone.app.z3cformdrafts seems to work okay now).
/Jason