xpdo - newbie, not getting past model schema, need help please!

Hi,

For days I have been trying to figure out what I need to do with the schema once it is written. Please could someone tell me where it needs to be saved, or where it should ideally be saved, and how to run it to get it to output the relevant tables etc and be able to start accessing the tables with code within the Modx Revolution framework?

It’s been baffling me so much and none of the literature I have read (which is quite a lot) yields much of the way of clues to me. Many thanks in advance, much appreciated.

:)

to start I would read this tutorial:
http://rtfm.modx.com/display/revolution20/Using+Custom+Database+Tables+in+your+3rd+Party+Components

you can also try out thisone:
http://modxcms.com/forums/index.php/topic,54753.0.html

Forgive me, but I have read and read and none of it makes sense. In the first link you give, for example, the top of the directory is named ’storefinder’ - where in all things Modx Revo should I put my equivalent directory structure? This is the question that nothing I have read answers. Someone please just give me a straightforward answer instead of directing me to more reading. I have read quite widely already and it doesm’t help. I’m not a coder and don’t understand coder’s techno language to be able to skip past a few blocks to get to where I need to be, but I can follow examples provided those examples are complete enough. Thank you.

In that first link, it does say:

First off, let’s take a quick look at our directory structure. This isn’t always how you have to do it - this one is specifically built this way for SVN; but it’s definitely recommended, especially with the core/components/storefinder/ structures...

So the tutorial is suggesting to put your custom components in core/components. The tutorial goes on to explain a suggested structure for the different types of files within your component directory.

But before you go a lot further here.. can I ask what it is you are trying to do? Developing a model to access a custom table implies that there will be some sort of php coding in a snippet or a plugin in order to access that model (ie table). If you’re not a coder, this part may just be the tip of the iceberg.

Thank you!

I’m confused about this directory structure. There isn’t only one place where there is a folder called ’storefinder’ according to this graphic. Where does the first ’storefinder’ at the top of that structure go? There is no clue given for this, so I’m at an equal loss as to where the ’storefinder’ and all the other subfolders should go too.

I’m testing things out, and yes, I do have a specific project in mind. I’m not a complete beginner, but I am not trained in Modx either! I could cope with most of Modx before, and then something called xPDO suddenly appeared. It may be using PHP etc, but it still looks like a foreign language to me and requires a very different approach - it’s a different kind of technology being ORM for a start. The new Revo is structured differently too. As said, the explanations already given in the documentation can still leave a lot to be desired and I think it’s also well acknowledged that there are gaps, but I am doing my best fill those myself before coming here. Despite the claims about how easy it is I see everywhere, it’s only easy if you understand it, until then it requires a lot more than I needed for the original Modx to learn (I was getting along quite happily with the previous Modx for a good number of years).

I thought Modx was meant to be for people to use more or less straight out of the box, who could get by with minimal PHP coding etc, as well as those who want to do more sophisticated operations with it? Correct me if I am wrong??? It would be a great pity if Modx lost that original focus over its development.

Quote from: hippychic at Sep 28, 2010, 04:07 PM

I thought Modx was meant to be for people to use more or less straight out of the box, who could get by with minimal PHP coding etc, as well as those who want to do more sophisticated operations with it? Correct me if I am wrong??? It would be a great pity if Modx lost that original focus over its development.

You can use xPDO with Revo or with Evo projects, but it’s not meant as a tool for non-developers. With Evo or Revo you can string together sites with pre-built Add-ons, nothing has changed there. In fact if you’re absolutely comfortable with Evo, it is still around and will have a new release in the not too distant future.

Part of the reason that you’re not getting much help is that *very* few people have yet done what you’re trying to do. I’m an experienced Revolution user and PHP coder and I’ve documented a lot of the xPDO methods, but I have yet to create a schema.

You haven’t told us what you’re trying to do, so it’s hard to know what’s relevant or if you need to use xPDO (or even know about it). A main point of xPDO is to make it easy to do database operations without having to use the traditional PHP database functions. So, you’d only need a schema of your own (MODx already has one) if all three of these are true:

1) You need to add one or more custom database tables to the MODx install.
2) You want to access those tables with PHP code.
3) You want to use xPDO to interact with them rather than traditional PHP DB functions.

If you’ve added tables to a MODx install before and used PHP functions to interact with them, that will still work. It’s worth learning xPDO if you’re going to do this often, IMO.

That said, I have to agree with you that the docs you were referred to are very vague on what to do with the schema file once you have it. I just went over them and I couldn’t figure it out from them either. They are for people creating Transport Packages that will install a third-party component to share with others. There is a definite need, IMO, for a simpler tutorial for people who just want to create an extra table or two and access them with xPDO without creating a full-blown Transport Package or having it SVN compatible (especially since we’re not using SVN any more).

This tutorial is more to the point for you, although it still assumes SVN so you can ignore all the stuff relating to trunk, tags, and branches.

http://rtfm.modx.com/display/~splittingred/2008/06/26/Writing+a+3rd+Party+Component+in+MODx+Revolution%2C+Pt.+I

For your purposes, "doodles" would be replaced by the name of your "component" -- it’s an arbitrary name and you can use anything you want.

The tutorial doesn’t say where the doodles directory actually goes, but I believe it would be assets/components/doodles. I would leave out the trunk directory from the structure, and move everything below it up one level, and omit the branches and tags directories. Then use this in the code:



The schema file should be _build/schema/yourComponent.mysql.schema.xml and the line at the end of the script will be:




I’m guessing here, so it may take some trial and error to make it work.

When and if the script works, the files you need to make your "component" work should be in assets/components/yourComponent/assets/model/

To get beyond that, I’d suggest installing the Doodles package and looking at how the snippet works.

Here is the line that initializes the system:



If you don’t set a &doodles.core_path parameter in your snippet tag, I believe it assumes that you’ve copied the files from assets/components/doodles to core/components/doodles.

I hope this makes at least some sense.

Someday, if I ever have time, I’ll do a tutorial on this. If you get it working, maybe you can do it.

Tutorials are best written by people who’ve just figured things out -- not people who have been working with things for a long time.

I’m riding that train right now. Discovery as I go...

As said all depends on what you want to do. Just a simple table with some CRUD operations or a full blown Custom Manager Page.

For both situations you can use the Doodles example - or alternatively the modExtra example - as a reference. I believe modExtra is more up to current standards.

Both have a clear architecture basically based on clear separation of client code and server code and the model-view-controller pattern (model: your db, view: your frontend, controller: your plumbing code to tie them together).

You will find all the model stuff (PHP, db, mappings) in core/components/modExtra. There’s actually a special directory for your schema files in core/components/yourProject/schema. I must confess that I have not yet been successful in generating class and mapping files from an XML schema file... I code them by hand as the method described in various docs was not working for me.

All client stuff is in assets/components/yourProject. This is covering all the Javascript files (basically ExtJS sources) that your project might contain. If you’re just doing CRUD in snippets on your own DB files you can skip this and just focus on the server side and look at core/components/yourProject/processors/mgr/. In this directory you’ll find subs for each entity you want to CRUD with PHP files.

I totally agree with your original post that it looks completely overwhelming. My approach was to just build my own small project by simply copying and pasting from the Doodles project. It took well over two weeks and loads of questions on the forum to get it all working.

Good luck - may the force be with you!

Just my 2 cents. If I’m talking nonsense, please correct me...

Also remember, xPDO is here as the foundation for MODx so it can be ported to several different DB engines. It is a wrapper for PDO itself though, and you can use xPDO (and thus MODx Revolution, since the modX class extends xPDO) as a way to just access the standard PDO methods available in PHP. A model is really only necessary if you want to build an object-oriented API around your RDBMS tables, or if you want to create generic MODx solutions that can be easily ported and used on various DB engines.

I completely understand the frustration. Developing in Revolution is a steep learning curve.

The documentation always illustrates ’best practices’ in terms of directory structures, file naming conventions, workflows and so forth. But you are essentially free to build your own add-ons however you see fit. You do not have to build xPDO classes to abstract your database and tables, you can just use PHP mysql functions. You don’t necessarily have to obey the MVC approach to your programming, just make simple PHP scripts to function however you wish. If time and the Revo learning curve are your enemies, code your add-ons however is easiest and most convenient for you.

Just keep in mind that the consequences of sidestepping best practices may include forefeiting the flexibility, security and conveniences leveraged by taking full advantage of the Revolution architecture. You also won’t be able to build your add-on as a package and share it with the rest of us.