masterofallarts

Martijn, thanks for elaborating! Finally it dawns upon me. I would not name the fields in the templates by the table headers, but simply dataN. I had always thought of things like array( 'color' => '$page->color', 'size' => '$page->size', 'amount' => '$page->amount . " pieces"' ); as the main source for table structure information, but I never could find where to put this array, if not in an include. I even tinkered with eval'ing the array values, because it would be nice to feed this array into a field on the product page, but I haven't been able to get anything of that to work. Anyone using arrays to define tables?

Sorry for my garbled question. MarkupAdminDataTable is no longer problematic. It is rather the way that table-page and row-page (from Martijn Geerts' post) are related. Are the row-pages subpages, i.e. children of the table-pages? I can't seem to wrap my head around the following paragraph of Martijn's: Only populated fields in the table-page (parent), filled with header names are used for the table headers Now you know wich fields to use from the child pages. Especially the word 'now' puzzles me. The way I understand it involves separating the level of the product page (in my case, say, "Computers", which is supposed to show a table of all computers) and the level of the individual computers (which would have the template 'computer') with an additional level that will take a page for each table (which would have the template 'computer', too). Is that approximately right? I have thought that the table headers are to be stored in the product page directly. That would feel more natural to me, and the additional level looks a bit clunky. Thanks for babysitting me through this. Oh yeah, I forgot that I have multiple sorts of products that I'd like to display that way, only with varying table columns and numbers of columns, too. I'm just looking for a way to store that table info in the product page of sort.

Hi there, I'm now in something like the OP's situation and quite happy to find this thread. I have been trying to build something with repeaters in order to store table definitions for certain overview pages, and I think that storing the column metainformation as pages is a brilliant idea. Trying to get MarkupAdminDataTable going, I must be missing something basic and obvious. Martijn Geerts posted: foreach($table as $row) { $table->row(array($row->data1, $row->data2, $row->data3, $row->data4)); } but I don't see how $row->dataN can already be populated at this point. What am I supposed to be doing here? How do I refer to my existing subpages? It seems I'm not getting the logic of the module. I'm now able to use MarkupAdminDataTable, hooray! Nevertheless, I'm not sure what to do with the columns as related to pages. I have a page for listing computers, one for listing monitors and so on, for a variety of stuff. Each of these pages has children with a template 'monitors', 'computers', determining the fields of the children. Also, on each of the parent pages, I want to show a table with data of its children. I am looking for a way of storing the table structure (column header and respective field name of the children, where to get the data from) in the parent pages. I could put up an include for each parent page that just contains this information in an array, but this feels redundant. At the moment, I have a few half ideas, but it won't come together. Thanks!

Thanks for your replies everyone. I'm sorry I haven't replied earlier - I forgot to follow my own topic. @Soma: It's good to learn that turning off the global flag is an option, seems to be quite exactly what I need - and @pwired: yes, it's really not as obvious to me as it surely is to anyone more familiar with PW - would have taken me ages to find out on my own. @MatthewSchenker: I would love to use the "invoice_number" field as the title! Sadly, it is just a string, and nothing precludes different vendors to produce identical invoice numbers. If I could combine the fields "vendor" and "invoice_number" into the "title", that would be really great! Like a mysql composite key. My gut feeling says that's impossible. But if anyone thinks otherwise, I would much appreciate hearing it! So again, thanks to all of you!

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.

Hey everyone, say I want to store invoices as pages inside PW, for later referral and storage as a scanned document, and to relate the items (themselves stored independently) listed on the invoice to the invoice. Say I have a template for invoices and have to use the title field. Really, I don't want to give every invoice a name, title or other identifier - they come complete with the firm that sent the invoice, an invoice number and a date. These three really are enough to identify any invoice. What to do with the title field? In my envisioned system, it is pretty much useless, but PW forces me to come up with a name for each invoice. Can I circumvent this? Can I somehow autoconstruct the title from the other inputs? Thanks a lot for any suggestion!

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!

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!

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?