|
[
Permalink
| « Hide
]
Penny Leach added a comment - 06/Nov/08 05:32 PM
Added some people I thought might be helpful. Feel free to add whoever wrote the repository stuff.
Two approaches:
1. You might be able to 'eval' the returned XHTML - I think I remember seeing this proposed as a solution somewhere previously but can't remember exactly where. http://ajaxian.com/archives/evaling-with-ies-windowexecscript 2. Pieforms (Mahara form library) solves this problem by keeping javascript out of the forms completely, instead each element exports what is badly named "headdata" - an html string to include in the <head> - and this is included on the page if the element shows up in any form on the page. Maybe mforms could do that too? From my experience with the repo api, we define elements for display with a json object for js and another way for plain html - this is currently non defined. (See http://docs.moodle.org/en/Development:Repository_plugins#print_login
 and Nigel's (2) does make sense, but AFAIK our JS (ala Quickforms) is custom built for the form in question ... (which is why it's inline) ... it could be very hard to separate it to a different file, I don't know. We can look into that. Then we could conceivably do this:
1) in php, call a method in $mform object to generate the JSON automatically, Otherwise you can just include current mform-generate pages in an OBJECT or something but that's not really AJAX any more is it Which brings me to: is it even a good idea to have a filepicker-like save dialog? We have it for repository because grabbing files is something you do within editors, within forms etc ... but I really can't see the benefit for portfolio ... KISS, right? Regarding repository API, Dan, yes this sort of thing might simplify things very slightly for the plugin developers but I think in this case it's going to be really rare that we need anything different than username+password, so it could be overkill to use mforms anyway ... As you can see I'm trying to avoid another big refactor when we still have basic functionality not working :-P Basic functionality not working yet for repository, file picker, portfolio, or mforms?
In terms of whether it's a good idea to ajaxify portfolio - well, I sat through a couple of demos of what's coming in 2.0 and got the feeling you were showing the file picker and not the portfolio because the UI isn't as sexy.... so I'd kind of like to fix that. Actually I talked through it with Nico earlier and it's really not that hard, or much work. This forms stuff is the only thing that trips me up. Still not really keen on spending time on a sexier UI here when:
Sorry if I sounded like I was criticising the initial work, I'm not. The filearea stuff was only implemented later, for example. We do need to finish this stuff for 2.0 somehow, but this is just about priorities in general, not this particular AJAX issue, sorry.
Back to this actual bug, are you able to quickly add a mockup here to describe what you mean? |
|||||||||||||||||||||||||||||||||||||||||||||||
Bug
Open
Major
find out a way to send mforms back in ajax requests
 |
|
