I have a need to build views in drupal of non-nodes, actually objects external to drupal. The api that I am calling against passes me back a stdClass object.
Anyone have ideas on how to get Views2 to display non-node objects?
My understanding of Views 2 is that it is meant to work with information stored in a database.
If you don't have access to the database against which the API was written, then consider writing the objects the API returns into a table. The easiest thing would probably be to create nodes from the objects. Then you could access them with Views 2.
This is similar to the approach taken by the Acitivty Stream module (http://drupal.org/project/activitystream). It creates nodes from the data returned by various APIs. Check out the module's code for examples of how to create the nodes:
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/activitystream/activitystream.module?view=markup
On the other hand, if you have access to the source database, you might consider exposing the tables of that database to Views directly. This is the approach taken in the latest Views 2 integration code included with CiviCRM v2.2.3, which you can review here:
http://svn.civicrm.org/civicrm/trunk/drupal/modules/views/
CiviCRM is a Drupal module that writes data to tables outside of the Drupal database -- not into nodes. The views integration code exposes most of those tables to Drupal.
Hope this helps.
-- Andrew B.
According to the Views 3 roadmap, Views will eventually work with non-SQL data sources. In the meantime, some very preliminary work has been done in this area, using the Flikr API as a proof-of-concept.
Fixed in latest 6.x-1.x-dev branch. VBO now supports users and comments in addition to nodes. A special hook_object_info can be used to support any other type of object. Please try it and let me know!
you have to expose custom data to views like described here:
http://www.darrenmothersele.com/drupal-blog/drupal-views2-handlers
http://views-help.doc.logrus.com/help/views/api-tables
Views is built for working with nodes + CCK exclusively. If you want to create views for custom pages, you'll need to code some additional module + theme pages.
Related
On a website with software documentation, I need to create a new version for a node always that the information changes for a new software release.
Here is an example:
For the product x version 1.0, I have a node (ID: 1000) that explains how to install the product.
When this product has a new release, the instructions need to change. Currently, what I do is to create a different node (ID: 1001) for product x version 2.0, also called how to install. The issue is that, since these two nodes are totally disconnected, as my database grows, managing these versions is getting too painful.
Ideally, I wouldn't have totally disconnected nodes for the same kind of information, but version that node as the product version changes. Is there any module that allows me to do it? If not, any idea on how to solve the issue?
Thank you
It sounds like you want to use node revisioning
https://www.drupal.org/node/320614
My approach would be to use a makeshift solution via entity reference and/or Rules. On a similar project, we used the Rules Link module to remove the author/ownership of the post but keep a reference for later processing by cloning the user entity in said rule to another field.
You could do the same: Automatically generate a new node with a reference to the old one and maybe copies of certain fields.
Depending on how much content you want to reuse, there's the Node Clone module and the Node clone on Save project seems like a fitting case, too (didn't test it).
Before the entity reference module got to be so mighty in Drupal 7 I often heard that sharing a common taxonomy term between 2 nodes would be another easy way to keep nodes „bundled“ – I'm not sure about the UX implications though.
Sorry, seeing that you're talking about documentation, another solution would be to simply activate the Books module and define a book for each product with the different versions as pages (see Drupal documentation as reference – you can easily style the structure, e.g. as tabs).
The module uses the menu system (up to Drupal 7) to keep a simple structure on top of the existing nodes. This approach has its UX limits on very large node counts.
Using the Book Made Simple module you can automatically generate a book on node creation.
I'm well aware of the standard SilverStripe Data Structure and table/field naming conventions. But how do you integrate SilverStripe with a pre-existing database? Is there any way to map existing tables/fields with a different naming convention to be useable by the SilverStripe ORM and DataObjects? Also, is it possible to use the ORM with two different databases?
In a recent project I had the same issue, and I solved creating views in the SS database over the CRM database, in order to present to SilverStripe the data in the way it likes. Obviously I also created DataObjects mapping the data, and so no dev/build is needed. It's not an easy way to do it, but if you're lucky and the second database logic is similar to SS logic it's a feasible task.
Now I have a CRM that write data into its database with its logic, and SS that reads it through views as if it were its own DataObject.
Good luck :)
I am afraid that, as far as I know, the answer to both questions is no.
I guess the best option would be to write an importer that connects to the old database, fetches the data, and then creates silverstripe objects for it.
If you have to run both systems at a time it will be come trick. The first thing I would consider here would probably be a rest api between the 2 systems, but not sure how well that would work out.
I quite often use Drupal's Views Module to build SQL that I paste into my code. It understands the Drupal database schema quite well.
Is there a module that would give me this functionality or can I factor this out of Views?
Would be cool of the Views module was extended to better support programmatic usage, but until then you might perhaps want to take a look at one of my colleagues attempt at creating something similar to such a thing: http://github.com/hugowetterberg/query_builder
Related to this might be the Services project attempt at providing Views data as a service, an effort that we right now are separating out into it's own module: http://drupal.org/node/709100 Might be worth follow since it's going to need some level of programmatic access to Views.
Another example of a module that's accessing Views programmatically is Development Seeds Litenode: http://developmentseed.org/blog/2009/feb/4/litenode
Update 15/12-2010: The EntityFieldQuery in Drupal 7 is almost like using Views programmatically to build queries - the difference being that EntityQueryBuilder works on only entities and fields and by that also with the bonus that it actually can build queries against any type of field storage in use - eg. a NoSQL database like MongoDB. Example can be found here: http://drupal4hu.com/node/267
Although this isn't the ideal way to do things, you can get the results of a view as follows:
$view = views_get_view('search');
$view->set_display('main');
$view->set_items_per_page(0);
$view->execute();
$items = array();
foreach ($view->result as $row) {
$items[] = $row;
}
This way, whenever you modify your views query, you don't have to re-copy the code. I do agree that Views needs to be split up into a query building api and a UI.
Yes, i assume views is the best to know what tables are used for current field, because many modules (and more in views) have hook functions, that provide some information about this field, table, and connection type with other tables.
Also you can read scheme of tables and fields via: http://drupal.org/project/schema
I'm curious- why would you use Views to build SQL, and then not use Views?
When it comes to more difficult things like many to many relationships, GROUP BY, COUNT, SUM, subquerying etc whatever the function calls for, it's best to write it yourself (especially if contrib modules have no views support and you need more than the node table).
For me, when Views can't get it done, I write a simple module that invokes hook_menu (to register the paths) with a callback that does the querying I need.
What's the "right" way in Drupal to create reports? I was hoping to use a view but am not having much luck. My goal is to create a table of rows containing three fields: user name, location, SUM of volunteer hours. Once I have this part working, I plan to expose filters for Location and Date.
Views Calc only allows you to group by one field. I know Crystal Reports and MSSQL Reporting Services and I was hoping to find a similar kind of thing for Drupal. Is there a framework, examples, or a module to help with this, or do I need to write a custom module implementing the views_alter_SQL hook to get the desired data for each report?
EDIT: I ended up getting it to work with BIRT reports, which gave a lot more power than Views could allow. Code is on my blog: http://nicholaiburton.com/blog/2010/creating-custom-reports-for-drupal
You could implement a views_query_alter but you might be better off implementing a custom views field handler, because I assume that your user.uid joins to hours.uid. This will probably be your best long term solution.
All you'd need to do is just tell views how your tables join and define the handler for the total hours. You can find help/docs -> http://views-help.doc.logrus.com/help/views/api
in any way, for Sum of Volunteer hours you need to build custom module, so building custom query more simpler, than attaching custom field to Views via it's hooks...
I am working with a Drupal 6.x system to create exercise / personal training programmes, and am using the CCK with content types of Exercise and Programme, where Programme contains a few header fields and a list of node references to the exercises it consists of. This works great and I can manually create programmes which work fine. I now wish to create a module which can generate these programs automatically based on a number of algorithms I have developed, the process will look like:
Load all exercises into array
Load users personal info (entered previously)
Establish best suited exercises
Create new programme content type
Save programme
An Exercise has a number of related attributes and although I could do all of the above using SQL directly into the tables it would be quite complex and doesn't feel right. I would like in step 1 to load the exercises as an array of Exercise objects (node_load?), and then create a programme object and save. Is this OO type approach possible or do I have to resort to manipulating the data directly?
The best way to tackle this problem would be to write your own module to do this.
Step 1 you can do node_load($nid) on all the excercies
Step 2 you can use user_load($uid)
Step 3 you'll need to iterate through the user object and match up to the appropriate excercies.
Step 4/5 I'd create a new $node = stdClass(); object and populate the attributes with the correct data then perfrom a node_save($node); this will assign it a $node->id etc.
If your unsure on what attributes are in your training program node, then do a print_r($node); on one you've created already.
Phil
Drupal doesn't provide any "cascading" save mechanism to save a hierarchy of nodes in one swoop. You'll need to build each node in code and call node_save() on it explicitly as described by Phil Carter.
The Node Export module can generate sample code for creating a node (complete with CCK fields) programatically.
There are a ton of modules that try to do the import thing right. Take a look at a comparison of them http://groups.drupal.org/node/21338
If you need strategies or examples of importing stuff into nodes, those are a great resource.
I don't think "creating" these programs is even necessary.
Why not just display a list of exercises that match your requirements and share 'characteristics' with the user.
I'd accomplish this by making the 'characteristics' be taxonomy. Then attached to users either with a profile, or taxonomy flag. Then display a list (perhaps even a view at first) and those with the same characteristic tags within exercises.
This would be dynamic and user specific and note require pre-loading a bunch of programmes.
A thought.