How to best implement archive number picker?

[masterofallarts]

Hey all,

this is my first post on the PW forum! I'm coming from Modx, and it looks like I'm not alone

I'd like to build a system that has a way for easily archiving CDs, as a part of an inventory management site.

Each CD belongs to one of three owners, each owner has an archive box of 80 CD slots, each labeled by number.

Say owner A has 3 CDs, sitting in slots 1, 2 and 10 of his box.

Now on adding a new CD to the archive system, I'd like to see a radio button input to select the owner for the new CD, and something, maybe a modal window showing me a grid representing the currently selected owner's archive box. A click on a free slot would set the archive slot number on the CD, and clicking on a non-free slot would do nothing.

Normally I would just program this in JS as a frontend solution, but PW's way of managing kinds of things like CDs in the backend has drawn me in. The radio button thing was really just a matter of minutes, using the pages fieldtype.

Of course my problem is now that I don't see at all how to get the slot picker into PW's backend. Maybe I need to write a dedicated fieldtype module, but I don't know where to start.

Any suggestions?

[ryan]

Of course my problem is now that I don't see at all how to get the slot picker into PW's backend.

The project you are doing does sound like a good fit for PW. I'm not sure I totally understand what a slot-picker is, so it might help to see a screenshot of what you are trying to achieve. But if it's something you will ultimately relate to pages, then need only make an Inputfield module that extends something like InputfieldSelectMultiple. If it's something where you want to handle the data storage separately, then you'll need to make both a Fieldtype and related Inputfield module. But give us some more details on this slot-picker (screenshot, if possible) and we can take it from there. 

[masterofallarts]

Hey Ryan,

thanks for your kind reply.

I'll expand a bit on what the slot picker is supposed to do, and I'll attach a sketch, for a lack of screenshootable material.

I am archiving the CDs for 3 people - Paul, Simon and Greg. Each of these has a number of archive boxes for CDs - Simon, for example, has 3. Each of the boxes has a capacity of 80 CDs. In Simon's Box Nr. 1, there's plenty of space left, as only slots 1, 2, 5 and 8 are populated. The CD currently being edited in the sketch sits in slot 5.

• Clicking any one of the free slots in the tabbed grid will set the CD's "archive box" and "slot number" properties (or maybe I'll ditch "archive box" property and just count slot 82 as slot 2 of box 2) accordingly and update the text to the right of the grid.
• Clicking any of the inactive tabs, for Boxes 2 or 3, will update the grid according to the data about occupied slots in these boxes and so give the opportunity to locate the currently edited CD there.
• Clicking on "Add a box" or "Remove a box" does as the label says.
• Clicking "Remove a box" in the depicted scenario brings up a warning: "Really remove a box? You will need to re-slot all CDs from the box you remove. To proceed, chose the box to remove, or click on cancel."
• Clicking on Paul or Greg in the Owner field instantly updates the Archive Slot field with the respective owner's data, because each owner has his own boxes, and chosing a different owner for the CD will mean putting it into another box.

So in general, the slot picker reads properties from a set of CDs (the ones of the currently chosen owner and his currently chosen box, determined via the slot picker's tabs) and builds an array of the slots occupied by these CDs. It builds a link for each non-occupied slot that will, when clicked, set some properties of the currently edited CD, and makes the remaining slots unclickable.

I'd like to have the possibility to set the system up in a way that permits boxes with more or less slots than 80 - this would, I think, force a split of the archive number property into archive box and slot number. But if this brings in more difficulty than I can handle at the moment, I can do without other-than-80-slot-boxes.

Thanks for having a look!

[ryan]

Glad to see another Model-M keyboard user around here. I collect them. Right now typing on a white label Model-M mini from 1991. 

Thanks for the sketch, that helped to see, and I think I understand now. I think that your system could translate to pages quite nicely, but you aren't going to get that visual "grid" unless you either: 1) write your own Inputfield; or 2) build this feature on the front-end of your site (rather than the admin). Using a Repeater would be another way to accomplish this, but you'd have to be willing to re-envision the system using the inputs that come with ProcessWire. If I were building something like this, and needed that grid, I would probably go ahead and build it as a front-end thing, and map to pages, using API code. 

[masterofallarts]

Thanks, ryan!

I appreciate the warm welcome in the forum.

I wonder how much a seamless integration (UX-wise) of the front-end implementation into the backend is possible. At the moment, it seems best to bite the bullet and make the new inputfield, because all the other data are entered via the backend and I want to avoid disruptions in the workflow of entering data. Or can one build this in the front-end and have the user not be aware of it?

One potential pitfall for the inputfield route comes to mind: Is it possible to refer to the value of another field? Remember that the grid must display the CDs owned by the person whose radio button in the Owners field is currently selected.

Other than that, is there any getting-started guidelines/best practices/learning resources for developing modules? I am quite new to programming as a whole, but eager to learn how to do it the right way from the outset.

Thanks a lot!

[ryan]

I wonder how much a seamless integration (UX-wise) of the front-end implementation into the backend is possible. At the moment, it seems best to bite the bullet and make the new inputfield, because all the other data are entered via the backend and I want to avoid disruptions in the workflow of entering data. Or can one build this in the front-end and have the user not be aware of it?

I think it's good to initially develop things in an isolated environment so that there aren't too many factors to consider. Especially with something fairly complex, as this sounds. So that's why I was thinking building it front-end and getting it working is a good way to get started. And once you've got that, converting it to another environment (like an Inputfield) becomes simpler. 

One potential pitfall for the inputfield route comes to mind: Is it possible to refer to the value of another field? Remember that the grid must display the CDs owned by the person whose radio button in the Owners field is currently selected.

Yes, a Fieldtype can give an Inputfield a copy of the $page being edited. But as for "live" changes, you'd have to use Javascript, just like anywhere else. 

Other than that, is there any getting-started guidelines/best practices/learning resources for developing modules? I am quite new to programming as a whole, but eager to learn how to do it the right way from the outset.

Modules are easy -- just a matter of filling in the required components. It's the other stuff you are talking about that sounds more complex. But if you want to learn more about module development, have a look at the /site/modules/Helloworld.module file. This wiki page on module creation is also a good intro: http://wiki.processwire.com/index.php/Module_Creation

[masterofallarts]

Thank you so much for your considerations and guiding!

You see me diving into another phase of learning stuff for the first time.

I think I'll try to build a module.

Should I ever finish it and anyone might possibly find it useful, I'll publish it on your site.