I created a custom table from a custom module using theme table; theme('table', array('header' => $table_header, 'rows' => $data)); the data that I'm showing can not be retrieved from views as i'm showing data from a 3rd-party services and this data is not saved in the database.
Is there a way to add VBO to my custom table?
Thanks.
no you cannot add vbo features that don't use the fields api of core drupal. the data from 3rd party services will needed to be imported into a field in order for BVO to work properly.
You have to declare the hook_entity_info() because:
VBO only supports entity (base or revision) table Implement hook_entity_info() and make your table an entity. Use EntityAPIController so that you don't need to write other boilerplate functions.
https://www.drupal.org/node/1282486
Yes is it possible.We can use contributed data module.This module bind the custom table data and relationship.after that we can integrate by views or create view for that data
table entity.
Related
I have a Symfony app using multiple entities.
A third-party analytic tool plugs to my database to create reportings.
What I would like to achieve, is being able to update the Symfony entity from the frontend in order to add new fields to the database tables (in order to get the new fields showing up in the reporting tool).
Anyone has a idea on how to achieve that?
Thanks in advance.
If i understand correctly, you wan't to be able to add fields to your entity dynamicaly.
I don't know if this is doable and if so, it would probably be messy and unsecure.
What you can do however is using sub-entities with dynamic key => values fields.
You should have one main entity, an entity with the list of your dynamic fields, a many to many relation between your main entity and your fields entities and a third entity with the actual values from those fields.
I am building a testing app where admin can build up questions for each test, each test will have its own set of fields (text, drop down, checkboxes, radio...etc), so I was wondering if there is any Meteor package that can help me with the dynamic form generation?
I've checked aldeed: autoform but as far as I understood all form fields (schema) must be defined statically, while in my case it is dynamically generated, saved/ retrieved in/ from the tests collection, where I save each test along with its fields (label, type, min, max...etc). Thanks
Autoform could automatically create your form based on a schema as it uses simple schema (or alternatively collection2). You could store and update your schema in the DB serialized for example and then use it with parseJSON.
var schema = $.parseJSON(jsonFromDB);
CollectionSchema = new SimpleSchema(schema);
{{> quickForm schema=CollectionSchema}}
Not tested but I think it should work.
I am trying to develop a New WordPress Plugin, I have tried to store the settings values in the WordPress built in DB table Options but there is problem storing and fetching the values so i decided to create new database table to store the values, Is this a good idea to create new db table and what is best way to create, sanitize and retrieve the valued.
Rather than write to the Wordpress tables directly, use the Wordpress APIs that serialize your data and write it correctly. The add_option function and the similar get_option function should be what you are looking for.
I have the following scenario:
My website db has a system table called "Companies", which includes an id field, companyName field, and companyImageUrl field.
How do I set up an umbraco document type for adding entries to this table ?
Maybe I shouldn't use a custom table at all ?
Thanks.
As far as I know, Umbraco doesn't support what you want to do out of the box (mapping a document type to a table that isn't part of the umbraco core).
One approach that might work is to create an action handler that syncs a Company doc type to your table when creating a node of that type.
It's a bit of a hack though. I've found that I've very rarely needed to create custom tables. What exactly are you trying to do with it? My guess is that you don't really need it and would be better off working with a doc type instead. Umbraco provides a variety of ways to get and act upon doc types from within custom C# code (check out the umbraco.NodeFactory namespace). You'll also get the added benefit of being able to easily interact with these nodes from XSLT/Razor.
I am working on a project to migrate a website from asp.net to drupal architecture. But the site content is very hierarchal and has a lot of references between entities.
for example: each content belongs to a category, and each category belongs to another category section. Now there may be another level of hierarchy even.
I am planning to make use of migrate module for migrating the database content and linking the migrated nodes via a node reference field.
But i am getting stuck with migrate module as i can't find a way to migrate the node reference field anywhere...
can anyone help me out with this...
Actually, it doesnt seem to be that hard .. in 2012. Yes, you have to keep track of source IDs versus import IDs, but the migrate module does this for you, in a neat little table. You can join that table in your source query, and update the node reference field with the nid of the .. referenced node. Ofcourse, the referenced nodes should have already been imported. If they werent, you can run an run an 'update' later and referenced nids get entered based on the latter imports too. In practice:
$query = Database::getConnection(
'default', 'mysourcedb'
)->select(
'mysourcetable','source'
)->fields('source', array(
'id',
'title',
'whatever'
'rel_rec_id'
)
);
$query->leftJoin('migrate_map_relimport','relmap','relmap.sourceid1=source.rel_rec_id');
$query->addField('relmap','destid1','rel_node_id');
The code above assumes you have a 'mysourcedb' with a 'mysourcetable' in it that refers to a 'rel_rec_id', and theres another import called RelImport that imports the rel table that rel_rec_id is refering to; it should have already run (or will run before you run an additional update). Do a migrate-status once you have the RelImport class to make sure the table exists.
To be able to make joins to the 'migrate_map_relimport' table, make sure map tables are written to the source database, not the drupal database. This is not always necessary, but here it is:
$this->map = new MigrateSQLMap(
$this->machineName,
array(
'id' => array(
'type' => 'int',
'unsigned' => true,
'not null' => true,
'alias' => 'source'
)
),
MigrateDestinationNode::getKeySchema(),
'mysourcedb' // connection to use to write map tables
);
and finally, assign the retrieved rel_node_id to your node reference:
$this->addFieldMapping( 'field_rel_node', 'rel_node_id' );
Yay, it is rocket science .. YMMV
As far as I know, you will not be able to do this entirely within the migrate module. You'll have to run a few queries directly in MySQL.
Essentially, you'll have to create an extra field in each content type to house their legacy ID's and an additional field for each legacy reference (in addition to the actual nodereference field). Load all the data into the content types (leave the nodereference field empty). Then once all of the entities are loaded in, you run mysql queries to populate the nodereference fields based on the legacy IDs and legacy reference fields. Once that's done you can safely delete these legacy fields.
Not the most elegant solution, but I've used it many times.
Caveats:
This is for Drupal 6; Drupal 7's fields implementation is totally different AFAIK.
For very large migrations, you might want to do your legacy field deletions through MySQL.
You might also take a look at the code for the Content Migrate module (more information at https://drupal.org/node/1144136). It's for migrating D6 Content Construction Kit (CCK) content to D7 Fields and it's been integrated with the References module.
It won't do what you need out of the box, as you're coming from an ASP.net site instead of a D6 site, but it may provide some clues.