my revo-developing questions

4,149 Posts

splittingred Reply #11, 17 years, 4 months ago

Quote from: Bruno17 at May 29, 2009, 12:16 PM

when I use
			$criteria = "`name` IN ('" . implode("','", $Tvnames) . "')";
            $tvObjects = $resource->getMany('modTemplateVar',$criteria);
I get only the fields of site_tmplvars. Without $criteria in getMany I get all fields from table site_tmplvars and modx_site_tmplvar_contentvalues

I think there is something wrong with my $criteria??

No, if you use a separate $criteria in $resource->getMany(’modTemplateVar’), you wont get the combined values. See line 163 of modResource.class.php:

if ($class === 'modTemplateVar' && ($criteria === null || strtolower($criteria) === 'all')) {

This is the expected behaviour. If you want to override the default criteria and provide your own, you’ll need to join in the modTemplateVarResource and modTemplateVarTemplate tables and values as well.

shaun mccormick | bigcommerce mgr of software engineering, former modx co-architect | github | splittingred.com

24,544 Posts

BobRay Reply #12, 17 years, 4 months ago

Quote from: splittingred at May 29, 2009, 07:40 AM

Another question to revo beta now: Is the new beta release the same as revision 5070?

Yes. beta-1 is the 5070 revision of SVN.

How about createing a Tag or a Release for that one?

Did I help you? Buy me a beer
Get my Book: MODX:The Official Guide
MODX info for everyone: http://bobsguides.com/modx.html
My MODX Extras
Bob's Guides is now hosted at A2 MODX Hosting

4,149 Posts

splittingred Reply #13, 17 years, 4 months ago

Quote from: BobRay at May 29, 2009, 01:11 PM

How about createing a Tag or a Release for that one?

Good catch. We’ll do that today before any other commits.

shaun mccormick | bigcommerce mgr of software engineering, former modx co-architect | github | splittingred.com

5,888 Posts

Bruno17 Reply #14, 17 years, 4 months ago

aah, so I have to use it like that?:

<?php            $c = $modx->newQuery('modTemplateVar');
            $c->select('
                DISTINCT modTemplateVar.*,
                IF(ISNULL(tvc.value),modTemplateVar.default_text,tvc.value) AS value,
                IF(ISNULL(tvc.value),0,'.$resource->get('id').') AS resourceId
            ');
            $c->innerJoin('modTemplateVarTemplate','tvtpl',array(
                '`tvtpl`.`tmplvarid` = `modTemplateVar`.`id`',
                '`tvtpl`.templateid' => $resource->get('template'),
            ));
            $c->leftJoin('modTemplateVarResource','tvc',array(
                '`tvc`.`tmplvarid` = `modTemplateVar`.`id`',
                '`tvc`.contentid' => $resource->get('id'),
            ));
			$c->where("`name` IN ('" . implode("','", $Tvnames) . "')");			
			
            $tvObjects = $resource->getMany('modTemplateVar',$c);?>

-------------------------------

you can buy me a beer, if you like MIGX

http://webcmsolutions.de/migx.html

Thanks!

MODX Staff
10,725 Posts

opengeek Reply #15, 17 years, 4 months ago

That’s the right idea, but perhaps I should ask what the usage scenario is at this point. I’m not quite following why you would ever need to do this, since all the current resource’s template variables would already be loaded automatically. Is this for a component and if so, what is the goal of this component?

Jason Coward
Chief Architect @ MODX
http://www.jasoncoward.com | http://twitter.com/drumshaman | https://github.com/opengeek

5,888 Posts

Bruno17 Reply #16, 17 years, 4 months ago

here is the topic what we are working on: http://modxcms.com/forums/index.php/topic,33985.0.html

I will try it in short words, sorry for my english.

As said at the beginning of this topic we, madeMyDay and Me are working on an frontend-Editing-Tool for modx.
What can you do with it:

create new content bloX which can have different chunks with one button-click into different containers
these bloX are nothing else as documents stored in subfolders for each container and can have a tv named ’chunkname’ for the different chunks to use
they are listet with a special snippet, which calls ditto for the listings, the most ditto-parameters can be used and some more for different configurations of the containers
you can have different containertyps for special things
can sort the bloX directly on frontend and store the sorting to menuindex or a given TV or commaseperated to a documents-TV on the listing-holder-page if you have choosed the reference-containertype
drag-drop from one container to another for moving, coping or referencing

edit the contents of each bloX directly inline, drag-drop pictures and more into the content or in image-TVs and so on
save the modifications on sortings and contents with one click on the save button in the control-center
But you can also edit other fields and tvs for each bloX and for the main-document in the control-center, the forms for that are loaded per ajax in different tabs
you can configure which fields and tvs you can edit in this control center witch template- or chunk properties and much more
you can also have custom chunks with snippetcalls in the contor-center and so on
there is also the posibility to edit not only recourses but also contents of custom-tables
........

What I have so far is now written for 096, because I’m familiar with its api. But now I guess it was perhaps a bad Idea to start this project for 096, because a lot of functions are deprecated or work a little bit different as in evo and I have to learn all the new functions and behaviers of revo. But I think its the better Idea to recode it, that it works in revo, than to develope it further for evo.

-------------------------------

you can buy me a beer, if you like MIGX

http://webcmsolutions.de/migx.html

Thanks!

MODX Staff
10,725 Posts

opengeek Reply #17, 17 years, 4 months ago

Hmmm, very interesting.

Personally, my advice would be to stay on track with this for Evolution for now. I think once you better understand some of the new concepts in Revolution, you will find better ways to accomplish this. My main point of contention is that Resources (aka Documents) are not the right place to create these so called bloX, because we are eventually transitioning Resources to have no associated content whatsoever. IOW Resources will eventually not contain any content fields at all: no pagetitle, no longtitle, no introtext/summary, not content, etc. These will become standard Content Elements (a Resource Variable vs. Template Variable) with a default value and all Content Elements will allow overrides by Resource, Culture/Language, and/or Version when directly related a Resource.

Also, the modResource class is defining a "convenience" relationship to modTemplateVar by overriding the xPDOObject::getMany() method, since it is not directly related, so I think the implementation in modResource should be updated to allow simple additions (like the IN statement you need to add) to the "base" criteria for querying the modTemplateVar instances without having to provide all of the joins each time. If it was a direct relationship to that table, this would have been handled automatically since it knows what needs to join.

Jason Coward
Chief Architect @ MODX
http://www.jasoncoward.com | http://twitter.com/drumshaman | https://github.com/opengeek

4,149 Posts

splittingred Reply #18, 17 years, 4 months ago

I personally would get it working in Evo first. Make it OOP and modular enough that you can easily transition the structure to Revo.

There’s a lot of JS/CSS work you’ve got in that that might be better to work out the kinks in Evo first.

Then work on learning the xPDO-based API for Revo, and convert it. That’s what I’d do, at least.

shaun mccormick | bigcommerce mgr of software engineering, former modx co-architect | github | splittingred.com

1,039 Posts

MadeMyDay Reply #19, 17 years, 4 months ago

Personally, my advice would be to stay on track with this for Evolution for now. I think once you better understand some of the new concepts in Revolution, you will find better ways to accomplish this. My main point of contention is that Resources (aka Documents) are not the right place to create these so called bloX, because we are eventually transitioning Resources to have no associated content whatsoever. IOW Resources will eventually not contain any content fields at all: no pagetitle, no longtitle, no introtext/summary, not content, etc. These will become standard Content Elements (a Resource Variable vs. Template Variable) with a default value and all Content Elements will allow overrides by Resource, Culture/Language, and/or Version when directly related a Resource.

That was our problem from the beginning. Create a new table for these BloX or use subdocuments. We decided for the documents because Bruno found a brilliant way to use Ditto for rendering them. So every feature of Ditto, all the functions for sorting, filtering and so on can be used. Downside is the addiional amount of documents, sure. But it works ;-)

Now, from my understanding of your explanation Jason, Revo will turn the documents/ressources into "real" Ressources which can be everything. A link, a file, a standard document or a special document without unnesseray fields. That would be great, so we could turn the document way into a special ressource way (modBLoX or whatever). Also Template Variables will be for templates, whereas I can put any setting to my special ressource. Correct? That would be perfect... Bruno what do you think?

So we stay with Evo, finish it and then - with the help of Revo experts - we try to convert it for Revo.

Make it OOP and modular enough that you can easily transition the structure to Revo.

Hehe, Bruno? laugh

My part is the GUI thing, HTML and JS. But we try to make OOP as much as we can.

MODx deutsch | Webdesign Karlsruhe | Ressourcen für Webdesign

4,149 Posts

splittingred Reply #20, 17 years, 4 months ago

Quote from: MadeMyDay at May 29, 2009, 04:58 PM

That was our problem from the beginning. Create a new table for these BloX or use subdocuments. We decided for the documents because Bruno found a brilliant way to use Ditto for rendering them. So every feature of Ditto, all the functions for sorting, filtering and so on can be used. Downside is the addiional amount of documents, sure. But it works ;-)

As an FYI, Ditto may or may not make it to Revolution. tongue

We might have a better alternative.

So we stay with Evo, finish it and then - with the help of Revo experts - we try to convert it for Revo.

Just let us know when you have API questions. Also, our Confluence wiki and the Revolution API Docs might help as well.

shaun mccormick | bigcommerce mgr of software engineering, former modx co-architect | github | splittingred.com