On March 26, 2019 we launched new MODX Forums. Please join us at the new MODX Community Forums.
Subscribe: RSS
  • P.S. On hydration, I’ve added an article:

    http://svn.modxcms.com/docs/display/XPDO10/Hydrating+Fields
      shaun mccormick | bigcommerce mgr of software engineering, former modx co-architect | github | splittingred.com
    • I would second the request for examples of a basic CRUD application. I think some threads about CodeIgniter have been driving Jason crazy (understandably)... but the problem I think many of us have is that the documentation of xPDO / MODx API is limited, so we turn to CodeIgniter (or similar).

      The tutorial here: http://svn.modxcms.com/docs/display/revolution/Using+Custom+Database+Tables+in+your+3rd+Party+Components
      has some confusing points and typos (see its comments). So specifically, I’d like to see the following:

      * Reverse engineering an existing table / database.
      * A detailed discussion of the xml schema files. I think it would incredibly useful just to compare MySQL "DESCRIBE my_table" commands with their corresponding XML schema files, especially if you listed common table structures (e.g. 2 tables, one with a foreign key; or 3 tables, 2 independent with a join table between them).
      * Discussion of MVC architecture, using a relevant example, perhaps discussing how Revo handles a page request (or some other known entity)
      * Perform basic CRUD operations using the Revo API
      * Compare a basic CRUD operation with other frameworks (this would be huge in luring in developers from other platforms).
      * Creating custom menu item in the manager to handle standard CRUD operations on a custom data type (MODx: beyond managing pages)
      * Using the MODx API to format / parse templates and chunks
      * Have a separate tutorial to cover making your own Snippet / Plugin in the correct format.
      * (possibly unrelated): creating contexts, e.g. setting up a web service that spits out XML bodies when pinged with REST-ful requests.
      * Discussion of MODx caching... e.g. if we write our own MODx CRUD operations, how can we set cache time-limits on various actions? How is it cleared?
      * Using Revo to connect to a different database engine other than MySQL (e.g. PostGres, or eventually Oracle)

      I’m happy to weigh in and try to write some of these... but the paradoxical difficulty is that there is little documentation.... lol.
      • @splittingred

        Thank you for the hydration article.



        outputting form html
        MakeForm will probably be removed from xPDO as it’s not really a DB-layer function (we’d rather separate it into another component). But a simple tutorial on how to do this would be easy enough. Can you elaborate on how this would work?

        I was hoping there was a way to set up validation at the model level and have form field creation, data input validation and error reporting handled by a form generation/processing class(es) (presumably as you say this is MakeForm). Elsewhere you say that validation is sometimes best handled outside of the db layer but personally I find this one of the most compelling reasons to use an ORM since it makes sense to me to define validation rules once. So I assume this means xPDOValidator is going to remain ’rudimentary’, which I find slightly disappointing; I would have liked to see things like being able to set up cascading rules, relationship validation rules and custom rules.

        To answer your question - perhaps an example of how MakeForm can be used in a sample CRUD application would be the best way to illustrate it’s capabilities and demonstrate best practice.
          Snippets: GoogleMap | FileDetails | Related Plugin: SSL
        • Oh, yeah... I’m with therebechips -- showing examples with regular expressions / data filtering would be huge. I agree that they make the most sense in the model layer... maybe as a helper function, although I’ve seen this in the controller layer too. Either way, it’d be great to see how to do it in MODx and then get some best-practices under our belts...
          • Data validation and form validation are very often different things with different requirements. xPDO allows for both as well as custom validator classes; I wouldn’t consider that rudimentary. Form classes can and will be produced that make use of both the schema-based validation and programmatic capability to add validation on the fly. MakeForm does not do this as it was created before validation was even introduced in xPDO.
            • Information on xPDO model-level validation has been written here:

              http://svn.modxcms.com/docs/display/XPDO10/Object+Validation

              Let us know what you think.
                shaun mccormick | bigcommerce mgr of software engineering, former modx co-architect | github | splittingred.com
              • Quote from: Everett at Sep 24, 2009, 06:16 AM

                * Reverse engineering an existing table / database.
                http://svn.modxcms.com/docs/display/XPDO10/xPDOGenerator.writeSchema


                * A detailed discussion of the xml schema files. I think it would incredibly useful just to compare MySQL "DESCRIBE my_table" commands with their corresponding XML schema files, especially if you list
                * Discussion of MVC architecture, using a relevant example, perhaps discussing how Revo handles a page request (or some other known entity)ed common table structures (e.g. 2 tables, one with a foreign key; or 3 tables, 2 independent with a join table between them).
                Definitely. Great ideas.


                * Perform basic CRUD operations using the Revo API
                This is all pretty detailed in the xPDO docs: http://svn.modxcms.com/docs/display/XPDO10/Using+Your+xPDO+Model

                But I could see how you want to apply this in Revo. (just change $xpdo to $modx). Can you give me an example case scenario?


                * Compare a basic CRUD operation with other frameworks (this would be huge in luring in developers from other platforms).
                Great idea; but I guess i’d have to know what all entails a "basic CRUD operation", and what that operation is being performed on.


                * Creating custom menu item in the manager to handle standard CRUD operations on a custom data type (MODx: beyond managing pages)
                Right, we used to have this, but things have changed. Now, the question is, should that CMP (custom manager page) use MODExt, or just be a simple HTML form?


                * Using the MODx API to format / parse templates and chunks
                Okay, what do you mean there? Can you give me a couple case scenarios?

                * Have a separate tutorial to cover making your own Snippet / Plugin in the correct format.
                A great idea. I’m assuming these pages aren’t covering it:

                http://svn.modxcms.com/docs/display/revolution/Plugins
                http://svn.modxcms.com/docs/display/revolution/Snippets

                Can you tell me how we’d expand them?


                * (possibly unrelated): creating contexts, e.g. setting up a web service that spits out XML bodies when pinged with REST-ful requests.
                Great tutorial idea.


                * Discussion of MODx caching... e.g. if we write our own MODx CRUD operations, how can we set cache time-limits on various actions? How is it cleared?
                http://svn.modxcms.com/docs/display/revolution/Caching needs to be expanded, definitely, then.


                * Using Revo to connect to a different database engine other than MySQL (e.g. PostGres, or eventually Oracle)
                This wont happen until we develop the xPDO drivers for it, which will probably be 2.1 or 2.2, so...we’ll table this one for now. tongue
                  shaun mccormick | bigcommerce mgr of software engineering, former modx co-architect | github | splittingred.com
                • Quote from: Everett at Sep 24, 2009, 06:16 AM

                  * A detailed discussion of the xml schema files. I think it would incredibly useful just to compare MySQL "DESCRIBE my_table" commands with their corresponding XML schema files, especially if you listed common table structures (e.g. 2 tables, one with a foreign key; or 3 tables, 2 independent with a join table between them).

                  http://svn.modxcms.com/docs/display/XPDO10/Defining+the+Database+and+Tables
                  http://svn.modxcms.com/docs/display/XPDO10/Defining+Relationships

                  Is there anything else we can elaborate on in those?
                    shaun mccormick | bigcommerce mgr of software engineering, former modx co-architect | github | splittingred.com
                  • For the readers of this thread I would like to notify this post (warning: long post!) which would be a bit OT here (no suggestions on specific documentation/tutorials I would like to see), but still is a suggestion about how I would like documentation/tutorials to be.
                    • I would really love a tutorial on how to hook up any third party application to the MODx system.
                      In a relatively extended way, with a case to study, showing a way to use the same login informations for both system (with the MODx API and xPDO) and showing how to set basic user level too in MODx for authorization (in the same scenario).

                      I also think that a tutorial on how to make template and bundle it in a package with a bunch of options could really be appreciated.