This relates to Drupal 6 and Views 2.
I'm not new to Drupal, but I am new to problematically using Views.
I have a custom view defined in a module which is integrated with data like this (I think):
$view->base_table = 'tblName';
I am integrating a third-party API. It returns me a pretty vanilla PHP object.
I need a way for list returns from that API to become the base_table for the view, on the fly. Is this possible? The ugly solution I was think of was making every return item a node, and then using those as the "base_table". I think that would work, but it seems ugly. I don't want a bunch of nodes hanging around for later.
Any suggestions? Thanks.
I'm not sure this is a good idea, but I ended up creating a routine based around Drupal's caching mechanism. I'm droping and creating a table on the fly and handing that table to Views. The table is populated every five minutes by the API. It can be forcibly re-populated by clearing the Drupal cache.
I tried using MySQL Temporary tables, but they didn't persist well enough. I wonder if there is a way to make them more connection-persistent, or to last a certain amount of time.
Related
What rule of thumb do you use for deciding to use node_load() or just writing a direct db_query()?
In a situation I'm looking at right now I need to get some node data and resolve data on two nodereference fields. So that would be 3 calls to node_load(). At some point here, would it be more efficient to construct the query with Joins directly?
This is for use in a self contained module that won't be distributed or used anywhere else, so I don't believe I need to worry about subverting node modification hooks (or do I?).
Edit:
Thinking about my question more, node_load() is only really applicable when you have one node to grab (and then maybe drilling down further into nodereferences like in my example). But as soon as you need to return more than one node based on some criteria, you're pretty much forced to use db_query right? Does Drupal have any abstracted API for writing queries like this?
Not a full answer (Not sure myself), just some hints.
node_load() is using a static cache (in Drupal 7, you can even use the entity_cache module to make it a permanent cache). If the nodes you are loading are being used a second time on the same page, that call will be free.
Querying CCK-tables is tricky. The schema structure can change completely based on configuration, for example when using a single or multiple values.
The reasoning behind using API methods for DB calls over direct DB calls is to provide a DB abstraction layer so that your app could move between supported database engines etc, also it enables your app to gracefully handle any schema changes (however unlikely) that core/module may make to the tables in question. It's also likely easier as #Berdir says for CCK fields and Node_Ref fields, but that depends on which you are more confident with Drupal API& PHP or MySQL...the payoff of doing it the Drupal way is increased future productivity and understanding of the codebase and what is possible :)
Oh and my rule of thumb is - Do it the Drupal way if at all possible (possible being variable depending on app time/cost/performance/whatever requirements)
I have a Drupal 6 website with about 20 pages. Inside every page, I need to create a lot of widgets with information either stored inside the database or from external web services. Most of the time, a "view" (from the view module) is just not enough to solve the requirement.
Up until now, any time I need such a widget, I create a new module which implements hook_block. Then, I drag and drop this new module inside the panel I want. I will need to create about 20 modules. This works pretty good. However, I'm not sure if this is the correct-drupal-strategy and I would love to receive some feedback from experienced Drupal developers.
A module can expose as many blocks as you want (in theory, admin/build/blocks will teach you otherwise ;)).
Have a look at the documentation of hook_block(), you just need to extend yours to return multiple block infos and then decided which one to show based on the $delta.
So you don't need 20 separate modules, maybe 2-3 and group the blocks somehow together because just a single module might be hard to maintain. The thing is that every single module makes your site a tiny bit slower (at least one more file to load, module_implements() needs to loop over every module for every hook and so on).
Without more information , it's hard to give any better advice. Maybe you could expose your data to views, or write a views plugin to display it in the way you want it, or...
Although Berdir's answer is pretty good, I'm impressed there's no link to any documentation in it. hook_block is meant for several blocks, and they can share functions that build their content. The API page is good, the example it gives defines two blocks at once.
You should notice each defined block has a delta (a key in the $blocks array). You can have dynamic deltas and use values in it to fetch data (passing a nid or uid and getting related content, for example).
I am struggling with the following use-case:
User amends an existing order. The order is complex - lots of related 'entities' (addresses, post options, suppliers, makes, models, various items etc). Across multiple http posts.
User wants to discard the changes.
--
I have an order entity and as the user is editing this I am making various changes to the entity associations e.g changing order.address, order.items.add(item)...
In a single post this is fine, but across posts I don't know how best store state. If I store the entities then I cannot save the changes as they are across different data contexts. I have read that it is bad practice to store the data context in the session state i.e. long-lived context. I can't save changes after each edit/post because I cannot roll-back (?). I really would like to work with the entities during the editing process rather than one big save at the end (taking UI settings and applying these in one chunk).
This must be a pretty common problem - it's driving me mad. Any help really appreciated.
Cheers!
We have a similar problem where we are building a complex business object through a multi-page wizard.
Instead of creating a partially complete business object at each step of the wizard, we create a dedicated wizard object that looks pretty similar to the business object, populate that through the wizard. At each step in the wizard, the wizard object is saved into the database. At the end the user can accept it and it is converted to a real business object and then becomes visible to everyone else, or they can bin it and no-one else ever knows it existed.
If this kind of approach was not suitable, I suspect you're looking at some kind of difference tracking, either at the entity or database levels. Neither are simple to implement, work with or manage in a system. The former would be some kind of calculation and storage of n changes to the entities and developing an algorithm to undo them, the latter depends on your RDBMS, but might include versioned rows or similar.
Yes its pretty much common for us. In most scenarios we use the MVC approach. Even without the actual ASP .NET MVC Projects, we use similar ViewModel with our Views/Pages/Scenarios etc. where there is no direct/single entity mapping to the Business Layer (in other words, Business.Entities). This is pretty much similar to DTOs.
It is always easy to use Disconnected EF. We retrieve data and discard the context, then transform the Entities into ViewModels/DTOs if necessary. When you need to persist changes, all you have to do is to create a new context, find the latest entity instance do the changes.
The Views/Pages/Controllers will be managing these ViewModels/DTOs. Tracking Changed and Deleted content can be done by introducing a HistoryList<T> (you can extend a List<T> to implement this).
Once done, using a Controller/Workflow/Component you can observe the ViewModel/DTO and do the necessary changes to your Entities using a new Context to retrieve and persist.
It involves a bit of a coding and I would say its not a perfect solution since it has its own pros and cons.
/KP
We have a content-type built using CCK. One of the fields is a node reference. The node picker is using a view to build the options.
A few days ago, everything was working well.
Today, it looks like all node reference fields using views to populate the selection options are displaying the wrong label. Every single label in the option is ``A'', but the actual node number is correct. The form actually works, just the labels are incorrect.
We have tried just about every combination of edit/save, disable/enable, reboot, clear cache, clone the view, rebuild the view, new view, etc, but we still have a big list of As.
If we create a brand new content type with a brand new node reference field, we get the problem.
Through some backup/restore exercises, we have determined that the problem is actually in the database and not in the code.
We can restore our last good backup, but we will lose a decent amount of work we have put into other parts of the database.
We enabled mysql query logging, and the view is actually being called properly, but we cannot track down where the problem is creeping in after that (unraveling the CCK / Views / Drupal plumbing is a challenge).
The install was build with latest stable versions as of April.
The problems referred to in http://drupal.org/node/624422 is similar, but our code versions include the patches mentioned.
Any ideas would be appreciated. Thanks.
I had a similar problem with using views for node reference, after quite a lot of hair pulling it turned out to be that my caching layer was buggy. I was using memcached, but memcached wasn't truned on on the server. It may be worth checking.
Thanks for the responses. We finally got to the bottom of this.
There was a module that was doing a custom hook_views_post_render() that did a prep_replace to rewrite some output. Unknown to us, there are instances where the $output parameter isn't a string, but an array, and this was causing the problem. One of those instances happens to be when you attach a view to a build a select in CCK.
I am developing a site that is saving non visible user data upon login (e.g. external ID on another site). We are going to create/save this data as soon as the account is created.
I could see us saving data using
the content profile module (already in use on our side)
the profile module
the data column in the user table
creating our own table
I feel like #1 is probably the most logical place, however creating a node within a module does not seem to be a trivial thing.
#3 feels like a typical way to solve this, but just having a bunch of serialized data in a catchall field does not feel like the best design.
Any suggestions?
IMO, each option has its pro's and con's, and you should be the one to make the final call, given that you are the only one to know what your project is about, what are the critical points of the project, what is the expected typical user pattern, what are the resources available, etc...
If I was totally free to chose, my personal favourites would be option #4, #1 and #5 (wait! #5? Yes: see below!). My guiding principles in making the choice would be:
Keep it clean
Keep it simple
Make it extensible
#1 - The content profile module
This would be a clean solution in that you would make easier for developer to maintain your code, as all the alteration to the user would pass through the same channel, and it would be easier to track down problems or add new functionality.
I do not find it particularly simple as it requires you to interact with the custom API of that module.
As for extensibility that depends from how well the content profile module API is designed. The temptation could be to simply use the tables done by said module for your purpose, bypassing the API's but that exposes you to the possibility that on a critical security update one day in which you are in a hurry the entire system will break down because the schema has changed...
#4 - Creating your own table
This would be a clean solution because you could design your table (and your module to do exactly what you need to), and you could create your own API to be used by other modules. On the other hand you would introduce yet another piece of code altering the registration process, and this might make it more difficult for devs to track problems and expand the system in a consistent way.
This would be very simple to implement code-wise. Also the DB design would benefit though: another thing to consider is that the tables would be very easy to inspect and query. Creating a new handler for views is dead easy in most of the cases: 4 out of 5 you simply use one of the prototype objects shipping with views.
This would be extremely easy to extend, of course. Once you created the module for one field, you could manage as many as you want by mostly copy/pasting the code for one field to another (or to inherit from the same ancestor if you go OOP).
I understand you are already knowledgeable about drupal, but if you need a pointer on how to do that, I gave some direction in this other answer.
#5 - Creating your own table and porting already existing fields there
That would essentailly be #4 minus the drawback of scattering functionality across various modules... Of course if you are already managing 200 fields the other way this is not a viable option, but if you are early into your design, you could consider this.
In my experience nearly every project that requires system integration (meaning: synchronising data for the same user in multiple systems) has custom needs for user registration, and I found this solution the one that suits my need best for two reasons:
I found I reuse a lot of the custom code I wrote from project to project.
It's the most flexible way to integrate data with the other system (in some case I even split data for the user in two custom tables managed by the same module: one that contains custom fields used by drupal only and one that contains the "non visible fields", as you call them. I find this very handy in a lot of scenarios, as it makes very easy to inspect and manipulate the data of the two systems separately.
HTH!
If you're already using the Content Profile module, then I'd really suggest continuing to use it and attach the field to it. You're saving the data when the account is created, and creating a node for the user at the same time isn't that hard. Really.
$node = new stdClass();
$node->title = $user->name; // what I'd use, or you can have node auto title handle the title for you. Up to you!
$node->field_hidden_field[0]['value'] = '$*#$f82hff';
$node->uid = $user->uid;
node_save($node);
Bob's your uncle!
I would go for option 3. Eventually even other modules will store the data in the database against a user. So you could directly save it yourself probably in a more efficient way than those modules.
Of course depending on the size of the data, you can take a call whether to add a new column in the users table or to create a new table for your data with the user's id as the foreign key.