Moodle

find out a way to send mforms back in ajax requests

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 2.0
  • Fix Version/s: None
  • Component/s: AJAX, Forms Library, Portfolio API
  • Labels:
    None
  • Affected Branches:
    MOODLE_20_STABLE

Description

I want to ajaxify the Portfolio code to make the UI similar to the file picker but while doing a walkthrough of how this might work with Nico we came across the following problem.

The portfolio API uses mforms as a standard way for plugins and pieces of moodle that export content to communicate their export-time options.

The way I imagined the 'ajaxification' to work would be that the js would make xmlhttp requests to a portfolio handler, which would call the same functions in the exporter library as normal, and send back XHTML as the response, which the js would use to replace the contents of the popup div.

However, in the case of mforms, the XHTML that gets sent back contains javascript, mixed in together. Some of this needs to be executed at the time the popup div is replaced and there's no good way to do this.

This bug should serve as a dicsussion for how we can find a workaround, because changing the code to not use mforms is really not an option, I think. It's the standard way to make forms in Moodle.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Penny Leach added a comment -

Added some people I thought might be helpful. Feel free to add whoever wrote the repository stuff.

Show
Penny Leach added a comment - Added some people I thought might be helpful. Feel free to add whoever wrote the repository stuff.
Hide
Permalink
Nigel McNie added a comment -

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 has information on "on demand javascript", which isn't quite the same thing, but may give some clues.

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?

Show
Nigel McNie added a comment - 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 has information on "on demand javascript", which isn't quite the same thing, but may give some clues. 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?
Hide
Permalink
Dan Poltawski added a comment -

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 MDL-16488). I really do not like this approach and it certainly feels like a step backwards so I agree a solution needs to be found (and its interesting that the same problem being hit).

Show
Dan Poltawski added a comment - 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 MDL-16488). I really do not like this approach and it certainly feels like a step backwards so I agree a solution needs to be found (and its interesting that the same problem being hit).
Hide
Permalink
Martin Dougiamas added a comment -

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,
2) have some client-side JS convert that into clean HTML, and
3) have all the client validation and GUI niceness in the form come from an included JS

Otherwise you can just include current mform-generate pages in an OBJECT or something but that's not really AJAX any more is it Your save dialog might as well be an ordinary browser popup window

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

Show
Martin Dougiamas added a comment - 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, 2) have some client-side JS convert that into clean HTML, and 3) have all the client validation and GUI niceness in the form come from an included JS Otherwise you can just include current mform-generate pages in an OBJECT or something but that's not really AJAX any more is it Your save dialog might as well be an ordinary browser popup window 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
Hide
Permalink
Penny Leach added a comment -

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.

Show
Penny Leach added a comment - 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.
Hide
Permalink
Martin Dougiamas added a comment - - edited

Still not really keen on spending time on a sexier UI here when:

  • We need the non-JS version to work too, can't we still simplify things in plain HTML first?
  • I'm not seeing any mockups of the proposed new UI yet so not quite understanding what you have in mind
  • There's still some big problems with Portfolio in Moodle 2.0 I'd rather see done first.... , such as
  • - embedded images in associated filearea are not exported in the HTML
  • - do we have any PDF support yet?
  • - portfolio buttons are not implemented in many places yet ...
Show
Martin Dougiamas added a comment - - edited Still not really keen on spending time on a sexier UI here when:
  • We need the non-JS version to work too, can't we still simplify things in plain HTML first?
  • I'm not seeing any mockups of the proposed new UI yet so not quite understanding what you have in mind
  • There's still some big problems with Portfolio in Moodle 2.0 I'd rather see done first.... , such as
  • - embedded images in associated filearea are not exported in the HTML
  • - do we have any PDF support yet?
  • - portfolio buttons are not implemented in many places yet ...
Hide
Permalink
Martin Dougiamas added a comment -

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?

Show
Martin Dougiamas added a comment - 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?

People

Vote (0)
Watch (7)

Dates

  • Created:
    Updated:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Moodle. Try JIRA - bug tracking software for your team.