Many-to-many GUI

[VexedPanda]

Related to #83, we should probably have a cleaner way of handling the GUI for many-to-many relationships than a multi-select listbox with a backend that deletes all relationships then re-adds them.

[VexedPanda]

These two files are what I use, which will hopefully prove a good starting point.

There's some app-specific code I need to remove, along with possible optimizations in the update function (it does a DB lookup for each displayed row, rather than a single db hit for all related objects).

[VexedPanda]

This would be awesome in 1.1, especially if we could do some jQuery around it. I may come back to this after addressing more important tickets.

[VexedPanda]

I've laid the groundwork for this in #364. Hopefully it won't be too hard to utilize for this.

[alex94040]

I'm guessing you envision a datagrid with a column of checkboxes to replace the multi-select listbox control, right? If so, that sounds like a great plan.

[VexedPanda]

Yeah. I'd say I've got it 90% there. I'm just haven't put it in a template yet.

[VexedPanda]

Fingers crossed, this is a fully functional version. It's basically a drop in replacement for the many-to-many templates, but also removes a couple display quirks that probably should never have been hard coded in the tpl files in the first place.

[VexedPanda]

Note that there's also a start to automating a filter for the datagrid, but it would require extending the data classes to provide a way for the user to point to the correct QQNode for the Name column. (I do this in my app by simply having every associated table have a name column in the db itself, and always pointing to that.)

[VexedPanda]

Note, this requires #364 v3

[alex94040]

Vexed - I encountered one small issue with the patch. The default URL to editing the associated objects was causing 404's on the generated drafts. This is because the drafts use the URL format like this:
/project_edit.php/1

And you were using URL's like this: project_edit.php?intId=1

This was causing a directory structure mismatch and a resulting 404.

I changed this default URL in the generated MetaControl? to be like the rest of the drafts (ex. /project_edit/1).

New patch uploaded; also did a tiny bit of formatting cleanup. Let me know how this looks.

[alex94040]

Patch with URL issues fixed.

[VexedPanda]

I'm unsure about the directory change you made there (adding ..) Aren't the pages using the metacontrol in the same directory as the edit pages (Since they should actually be the same pages)? Otherwise, it looks fine. :)

[alex94040]

Vexed - please see my comment above about the patch, that explains why I made the directory change. If you run the codegen with the old patch, and then look at the drafts:
- Click on any project to edit it
- In the project editing form, click on one of the associated Person objects - you'll get a 404.

Test it out yourself if you'd like.

[VexedPanda]

I'm still confused by this. I get the change to pathinfo notation, and that's fine.

$strURL = '../<%= QConvertNotation::UnderscoreFromCamelCase($objManyToManyReference->VariableType) %>_edit.php/'

It's the introduction of the ../ at the start that confused me. I couldn't see why that would be desirable.
But then I realized that the pathinfo notation screws it up otherwise.

Unfortunately, introducing ../ then kills things whene there is no path info notation, such as when adding a new project, causing new 404 errors again.

I also note that there isn't a default that will work in both panel and non-panel drafts, so perhaps we should simply default to no URL, and possibly open a new ticket to have the drafts themselves set up a correct one depending on the situation.

[alex94040]

I love the approach you're suggesting. The panel and non-panel drafts should simply specify the URL while calling the _Create() function. And let's kill the default.

One issue: order of parameters in the _Create() call. Here's the tradeoff:
- almost everywhere I recall, ControlID is an optional LAST parameter.
- we need to add a new $strUrl param. If we add it FIRST, then we're breaking the API (it's not a drop-in replacement anymore). If we add it LAST, we're inconsistent with the rest of the API.

I vote for consistency here; we're making a RADICAL change to the code-generated UI (datagrid instead of a label), so people will most definitely want to revisit this piece of code. On that same note: we might actually want to call the new control "dtg" instead of "lst", to outright break old forms / not let them keep working in subtly wrong ways. Also, the new thing actually IS a datagrid. No purpose in calling it a listbox (lst prefix).

What do you think?

[VexedPanda]

I agree with changing lbl to dtg.
But on the parameter order, I took guidance from datetime lables, which already use:

public function lblSomeDate_Create($strControlId = null, $strDateTimeFormat = null) {

So the second parameter is formatting related, same as here.

[alex94040]

You convinced me on the order of parameters. Wanna roll a new patch?

[VexedPanda]

I think this takes care of it. It has drafts link correctly, avoids arbitrary relative paths, and switches to dtg.

[alex94040]

(In [905]) Fixes #294 (Many-to-many GUI). Code by VexedPanda?. Review/testing by alex94040. This checkin is for the 1.1 branch.

[alex94040]

(In [906]) Fixes #294 (Many-to-many GUI). Code by VexedPanda?. Review/testing by alex94040. This checkin is for the 2.0 branch.

[alex94040]

(In [910]) Fixes #294 (Many-to-many GUI). Code by VexedPanda?. Review/testing by alex94040. This checkin is for the 1.1 branch. I had to do some non-trivial merge conflict resolution, please review.

[alex94040]

Sorrry, changelist [910] had nothing to do with this ticket.