Quote from: jzigbe at Oct 10, 2009, 06:19 PM
Documentation without demo content is very difficult to understand.
For example where does the css file go?
It’s no different than in Evo or 0.9.x. You can put it anywhere on the filesystem, on a CDN, or create a CSS Resource in MODx.
Demo content is good, but also can lead people to believe there is only one way to do something, which is generally not true in MODx and can limit innovation. That said, when we release MODx 2.0.0 final, we we also be putting various demo content packages in the Extras repository for people to download and explore with various examples. Hopefully folks will start creating some packages like this and contributing them as well.
Quote from: Everett at Oct 06, 2009, 05:44 AM
I’m asking for examples of how to use MODx and xPDO to do the dance between code and HTML forms that comprise the "Create", "Read", "Update", and "Delete" operations that are the foundation of so many web applications.
The "Read" option is the simplest... just justing xPDO and MODx (but it would be good to review it in Revo), but also show the new formatting options AND it would be useful to show recommended ways of passing URL values etc. to the model. E.g. where yoursite.com?id=123 becomes infused with the database query of "WHERE id=’123’";
You do this as you would in any PHP script, using REQUEST variables. Then use the methods of xPDO, like getObject() to READ the data. At that point you can do whatever you want with it, though the most basic operation would be to $modx->setPlaceholders() with the data or use $modx->parseChunk() to isolate the placeholders into the scope of a Chunk. And these are just the simplest operations; the possibilities are endless. But for sanity’s sake, here is an example:
$objID = $_GET['objID'];
$object = $modx->getObject('myObjectClass', $objID);
return $modx->parseChunk('myObjectChunk', $object->toArray());
The create and update operations are more complex because they involve a form and a form handler. What’s a recommended way for using forms to pass data to a handler? Should the handler be the same page that houses the form?
That’s up to you and your needs. It could be the same page or separate depending on how you write your scripts. You may want to process it with a Resource that accepts Ajax requests and returns JSON responses, or you may want to simply read the POST and process it. Using $myObject->fromArray($_POST) and $myObject->save() is the simplest way to create or update xPDO objects from these requests, assuming you name the POST variables the same as the object fields.
Quote from: Everett at Oct 06, 2009, 05:44 AM
How about validation?
See the
xPDO Validation documentation first, then use the validation responses to build and present error messages to the user and present the form again, perhaps with placeholders filled in with error classes. Or use Ajax to process the form in another Resource and return JSON data that is processed by a script on your form that highlights the fields that fail validation.
Quote from: Everett at Oct 06, 2009, 05:44 AM
If the form fails validation in the PHP layer, how can you repopulate the form data or issue error warnings without going through the nasty slop of php/html that comprises most web forms.
Save the POSTed data to SESSION, or if you need it to persist past the session, you could look into the modRegistry service which is like a basic message queue. Examples of modRegistry will be coming, but you can find basic usage examples of it in the MODx core, specifically the read.php and send.php in core/model/modx/processors/system/registry/register/.
Quote from: lossendae at Oct 10, 2009, 11:51 PM
For example, let’s say that i want to write a plugin to allow a user to connect on my MODx website with his Twitter account.
How i can i do that ? How do i plug the external application into MODx? Should i stock the token in the database ?
If the user has already an account with a MODx Password but want to connect himself with his Twitter account, how can i manage that case ?
I talked about Twitter because the process could be the same with any third party after. The exemple can be a good base to let the communauty build their own plugin for facebook, or any social application.
Store the token in the properties of your Snippet, or in a custom table, or in user settings. This process is going to be different for every 3rd party service and the way you want to use it. And this has nothing to do with the MODx security system, so I don’t think that was really relevant to Shaun’s question. It seems like you are asking us to write complete components for you. But this is a framework with an API for programmers to build the components with. Start by learning the API and asking developer questions.
Quote from: lossendae at Oct 10, 2009, 11:51 PM
On the same subject, if i want to use SMF within MODx, should i use xPDO? How do i manage the session between each system.
Do you want SMF to be the user system or MODx? Or do you want to synchronize the user systems? Each system manages it’s own sessions so the answer to that is, you can’t, but you could write a custom user class or session handler class. However, these are advanced solutions that require intimate knowledge of the workings of the core API. There are no simple answers and we’re likely not going to have time to figure this out for SMF unless someone is funding the effort. We use SMF at modxcms.com and have no user integration with SMF because it is a very difficult and time consuming task, IMO, because SMF does not have web services for handling this and requires you to write hooks that are very complex (at least that’s my opinion).
Quote from: lossendae at Oct 10, 2009, 11:51 PM
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.
What options? This gets a bit complex - is this template being bundled with TVs? Chunks? Properties? etc...
Exactly.
A guide to build a complete theme ready to use.
With several options, bundled snippets, chunks and TV’s. If possible, a way to verify if bundled snippet’s are already installed.
Let’s say a basic theme with:
- A tv to control the layout (1 or 2 columns)
- Quip bundled with verification
- Chunks related to the theme
- An installation process to set basic informations
These will come in time, but there are hundreds of combinations that could be realized here and everyone probably wants a different set.
We need folks with PHP knowledge to explore the API, core processors and component build scripts in our public modx-components SVN, learn about them, innovate with them, and help us contribute to this effort. We can’t wait for Shaun and I to exemplify every possibility in a tutorial, because there are simply too many things to cover. And every single one of these things is exemplified in the MODx core already (at least from a PHP coding perspective). I’m not saying we aren’t going to write more documentation, tutorials, or components that exemplify these things, but we could sure use some help... please?
Remember, we also have to fix bugs, prepare core releases and do client work to feed ourselves.
☆ A M B ☆
☆ A M B ☆
MODX Staff
