somewhat urgent need for links to resourses

Hello all. Hopefully i am putting this in the correct section. Like a real noob, i have no idea where to find this information?

BACKGROUND (pre-story)
(.net mvc/RoR/cakephp) type of thinking. I have already generated my own models from the database (scaffolding). I’ve run into some road blocks and i’m hoping someone could straighten out my confusion, then point me in the right direction of the necessary documentation.


1)How does one create a plugin? Not... how do i tie a model into an event. Literally, how is the entire thing configured. Where are the snippets, chunks, templates etc in FILE form so it can be packaged and moved? What is the required layout?

1b)What is a controller in modx? It doesnt seem to have the same importance as a controller in (.net mvc/RoR/cakephp) etc. How are all the fiels in a plugin tied together?

2)How do i create a package? I have the following link but it seems very manual. Can someone confirm that this is tutorial is complete and that this is the only way to package a plugin?
http://rtfm.modx.com/display/revolution20/Creating+a+3rd+Party+Component+Build+Script#Creatinga3rdPartyComponentBuildScript-PackaginginObjects

2b)Once a plugin is moved, how exactly does it expose its elements? Specifically, how do you get them into the gui? Hopefully there is a better option than creating my own gui snippets or manually entering them into the database?

3)How does one setup a provider? What the the technical requirements?

Maybe i’m expecting that the whole process would be way more automated. Am i just blind? Please explain and then point.

-strongdev

here are some answers for anyone that found this post interesting

1) plugins can tie into files on the server or elements in the database. The plugin area is simply a hook into your functions which can be attached to an event. Once your code is "included/imported" and initialized, how its organized means nothing to modx.

1b) somehow i thought modx was based on mvc. Maybe it is somewhere in there at the file level. The only real references to controllers are in plugins and in that case they seem to only be config/initialization files. In fact, i’m getting the strange idea that this product is treating the resource/template relationship like a controller too.

2)Dont make the mistake i did of learning what a vehicle is etc. Come to find out there are already plugins out there that will help you to package a product.

2b) Once those files are moved to a new home, you can have a routine that checks for the absence of elements and then adds them to the database. If they arent put into the database, you will have to access all of your files through importing and referencing.

3)No answer to this yet.

As before, i’m still open to someone setting me straight but until then, you can marvel at my limited insight

in my small opinion there is little mvc here. Simply a product that offers several levels of separation between logic, data, etc

I can’t tell from your post, but It may help you to know that MODx plugins are a particular kind of MODx object that listen for MODx system events (essentially hooks into MODx process) and step in to do further processing when those events fire, then return processing to MODx. Most MODX add-ons are not plugins -- most are snippets, which are encapsulated PHP code.

Plugins are abstract objects and the location of their code is irrelevant. By default, their code (along with that of the other MODx objects like chunks, snippets, resources, templates, template variables, etc.) is stored in the DB, but it could be in a file (and, at present, they can "include" code from a file).

There’s information about how MODx works at the site in my sig, but with little coverage of the MVC aspects of MODx.

This may help in that area:

http://rtfm.modx.com/display/revolution20/Developer+Introduction

If you want specific answers to your questions, you need to be much more specific about what you’re trying to do and why.

Welcome to MODx.

hello a reply thanks

I definitely appreciate the help and welcome to the community. I have 2 simple goals

1) I really want to re-skin the manager and hide 90 +% of it for a specific user group (the most rookie internet users).
1b) If i cant re-skin it and hide what i dont need, i would like to bring specific sections of the admin outside of the manager folder.
2) I want to create my own plugins and distribution area

ROAD BLOCKS
I know very little about modx but hiding 90+% of the admin seems impossible. Also because the admin is all wrapped up in one file, ("manager/index") which calls the different parts of the manager, i found it impossible use/extend/import these different aspects outside of that manager folder. The "modext" javascript files don’t seem to extend the manager outside of that folder either. soo...

HERE IS WHERE I AM
1) the first aspect i wanted was front end editing of tv’s. i have that now, made it myself for textareas, text, and images
2) I wanted to created an admin area that isnt as complicated (for the most un-savy). Doing that right now. user management, plugin management, etc all outside of the manager folder.
3)I have that software packman that will do package creation.

SO specific QUESTIONS:

1) I want that resource tree to be available outside of the manager area/folder also. I am guessing that i will probably have to remake that myself also?
2) I want to create my own distribution area. How would i go about that?
3) If i make my own model, xml mapping, and move it to the core folder, do i still need to import it to use it as an xpdo object?
4) Are the values for tv’s stored any other place in the database other than the "site_tmplvar_contentvalues" and "site_tmplvars" (default)?
5) How do i quesry the database? What am i missing here? is it

$stmt = $modx->prepare();
$stmt->execute()
$user = $stmt->fetchAll(PDO::FETCH_ASSOC);

OR

$users = $modx->db->query();
while( $user = $modx->db->getRow( $users ) )

ugg.. simple question. I completely understand how xpdo works...cute. How do i avoid it 100%?

The MODx Revolution manager is extremely customizable. You can easily hide just about everything.

You can hide the element and file trees with a policy that doesn’t include the file_tree and element_tree permissions.
You can limit the parts of the Resource tree seen by a user with a tree_root_id User Setting.
You can hide, rename, and/or reorganize the Manager’s Top Menu in System -> Actions using custom permissions in Manager->Actions.
You can hide or modify parts of the Create/Edit resource panel in Security -> Form Customization.

You can use straight PDO to query the DB, but --trust me -- xPDO is very easy to learn and will save you a ton of time in the long run.

See this: http://bobsguides.com/revolution-objects.html