I'm doing a project for a surveying company in Drupal 6. Ultimately, employees will need to enter measurements into a new content type. Currently they do it in a big Excel spreadsheet that has a bunch of macros to do calculations between cells (Meters to Feet, m^2, some pricing stuff).
My question is:
How would one go about replicating the functionality of this spreadsheet best in Drupal 6, keeping in mind the amount of data the employees using this system gather varies between projects (I.e., 3-floor house versus 1-floor with basement; etc.).
I have two ideas so far:
Create a new content type and populate it with CCK fields. Use Sheetnode's CCK functionality to drop Sheetnode CCK fields to replicate the spreadsheet exactly. Use Views to display this data other ways.
Create a new content type and populate it with CCK fields. Use Views (and possibly something like Views Calc) to get varying measurement values.
That said, I'm completely open to suggestions outside of these two implementations.
Thank you!
I dont have an answer so much as a caution. I did a project where a number of pieces of content were rendered simultaneously on a page, each piece being in its own node. The down side to multiple nodes is the performance hit you will take having at least one (possibly complex) query per node.
So in this case, if there were many many lines in the sheet, and each line was a node, you might take a pretty heavy performance knock.
This might be acceptable - but I thought I'd give you the heads up.
This might be one of those times where its best to actually create a purpose-built mechanism on-top of the Drupal API instead of using nodes+CCK.
Like I said, I could be being over cautious. It depends on your exact usecase.
HTH!
This seems like the kind of question http://drupal.stackexchange.com was made for...
I ended up doing this with jQuery, Measured Value Field and Flexinode; see: Auto-updating width/length/area using jQuery and Drupal6
Related
I know how to make custom fields for my custom post types. But I need a pretty complex custom field this time.
I'm making a website about agricultural machinery. There are a lot of types of machines. For every type of machine there are some products available with properties like size, mass, diameter, capacity, ....
Per type there is only one description, one title and one image needed. So my custom post-type machine contains posts (custom type = machines) with the basic information. For every machine I would like to sum up all the different size - mass - capacity - prize information in a table. I know I could just create a html table in the description, but I would really like the data to be structured so I can nicely style it, and eventually even do structured searches for price and stuff.
So ideally I would like to have a custom field that looks a bit like an excel sheet where I can create some columns and add rows per available product in the category. Any ideas how I can do this?
EDIT: I'm trying out the Types wordpress plugin http://wordpress.org/extend/plugins/types/. There's an option to group custom fields together and also an option to allow multiple instances of one field. Would be useful for me if there would be a possibility to allow multiple instances of a group. Does something like that exist?
EDIT: This looks promising. http://wp-types.com/documentation/user-guides/bulk-content-editing-with-fields-table/
I will look into it and maybe answer myself if it turns out to work :)
It seems like wp-types had the solution all along.
http://wp-types.com/documentation/user-guides/bulk-content-editing-with-fields-table/
This is what my custom data table looks like now:
Behind the scenes, all data is not actually saved in a single post. But wp-types allows you to create hierarchical relations between post types, and then provides a way to quickly create sub-posts straight from the parent. That's awesome enough for me.
In my case I created two post types. One called machine-type and another called machine.
machine-type holds all the basic information about the machine (title, description and image) while it's sub-type machine holds the specs for any of the different variants.
Currently I have a DB structure in MySQL with a few dozen tables with various foreign key linkages among them. All of the data is in files that I'm going to load in, so I'm hoping I can port the design over to a storage system that works with Drupal 7, since I can simply setup something (using the Feeds module?) to get my data in a way that Drupal 7 likes. The ultimate purpose of this is for lots of manual human revision, linking together entries in tables with relations and possibly revising some field data that looks wrong. So the whole goal is to make the human interface for viewing and editing (particularly adding) relations in Drupal 7. The question is, what is the proper way for the data to be stored so I have to write as little module code as needed?
It seems to me that I would choose one of 3 modules to accomplish this task:
Relation
Entity Reference
Data
Relation and Entity Reference would allow me to store all of my data in nodes (entities?) in Drupal 7, so Drupal would have "native support" for handling all of the stuff. However, I expect there to be 100s of millions to low billions of nodes with perhaps up to ~3 relations to other nodes in each. How efficiently does Relation or Entity Reference handle this when referencing foreign data (and perhaps grabbing referenced data from that reference, and so on) with Views and the like? Can they support a node having a null reference, since many will be null until a user can set them (so I'd need a way to also have a view to find nodes with particular null references)?
Data is another possibility, but it's in alpha and I wonder about its stability and efficiency. It also seems to me that having all of my data stored in an external MySQL database instead of in Drupal nodes defeats the entire purpose of using Drupal in the first place. Is my feeling on this correct?
I'm having a difficult time nailing down what I would need to manage my content, which seems odd considering Drupal 7 is a CMS. I have to be missing something here, but I'm not sure what it is. What is the most mature module(s?) for handling/interfacing with this large quantity of inter-related data and being able to go through and have a user mostly setting up and managing the links (so "foreign keys") between "tables", along with perhaps field data review and revision? Are there any that would suffice?
Relation and Entity Reference would allow me to store all of my data
in nodes (entities?) in Drupal 7, so Drupal would have "native
support" for handling all of the stuff. However, I expect there to be
100s of millions to low billions of nodes with perhaps up to ~3
relations to other nodes in each. How efficiently does Relation or
Entity Reference handle this when referencing foreign data (and
perhaps grabbing referenced data from that reference, and so on) with
Views and the like?
If your need the Data to display, another model will not help you. You might need some Pagination or give your query an maximum depth of recursion to load only the entities you are interested in. I guess using something that is already supported will save you a lot of work.
Without benchmarks you can barely find your bottlenecks. So go the easiest way which seems to be the Entity References and optimize as needed. You can create some test data to find limitations early. But there will be ways to optimize the requests later for sure.
I'm trying to build a Drupal site in which users can input records containing data about "customers", "employees" and "sales".
I would like to be able to create a form(s) which takes data about a sale/customer/employee and can be associated with a record of a customer/employee(who made the sale)/sale.
I would also like to be able to display records showing a list of sales or customers or employees in which when clicking one record, it will open a page displaying all the relational data.
I'm new to development and am searching around like a headless chicken lol. I was thinking of using content types for sales/employees/customers and using individual nodes for each record then using something like views to displays filtered lists, but I am unsure if this is the best way to go about/structure it (maybe I should use separate custom tables or database and use a custom module to fetch the data?). It would also be nice if some of the fields can populate other fields based on it input and also if some fields can utilize a sort of auto-complete by garbing data from other records, or is that asking way too much?
Thank you for any suggestions you might be able to give me.
I, for one, would certainly prefer using a custom separate database and leave drupal databases to its own devices, if you would ever need to upgrade the site to a higher version of drupal it helps if you don't modify it, and also consider using webform (http://drupal.org/project/webform) as it makes development easier both in components and hooks.
I have a CCK field price which the user can fill in. I would like to create a search form with dropdown price field with different ranges (such as below 100$, 100$-1000$, more than 1000$). The problem is that the user input is an integer so I cannot achieve range search using filter exposure. The user would have to specify the exact value to perform searching, but this is rather useless. Is there a way ( amodule, etc) to create ranges out of integer values so that the user is able to perform range based search?
Obviously people grab views and CCK for most solutions. But often a small module sith just a hook_menu(), a calback and a theme function will suffice.
In that callback you can perform whatever complex query you want.
Such modules, most of the time, contain less then 100 lines of PHP.
If you know PHP such a functionality might take you less then an hour to build. Whereas writing addons and behaviours for CCK and Views often costs much more.
The advantage of building views and CCK addons, is that your code is better re-usable.
The way I did it in the past was to use hook_form_alter to change that field to a select drop down range (a min and max drop down), then alter the views query if a value was provided.
The other way to do ranged facets would be to explore Apache Solr integration or Search Lucene facets. Keep in mind that its not exactly plug n play tech, though.
To sort out out your price into various categories you need to create a CCK Select list and then populate the list automatically using the Rules module. You need to also hide this select list using content permissions.
I've created a mini-case study on graphing using Rules & Views. As part of the mini case study, it shows you how to categorize the cost field using Rules -- which is precisely what you want. It also shows you how to hide the field using content permissions. Please check the below link for a video:
http://www.noparrots.com/content/mini-case-study-creating-a-bar-chart-in-drupal
This is a purely theoretical question (at least until I start trying to implement it) but here goes.
I wrote a web form a long time ago which has a configurable section for getting information. Basically for some customers there are no fields, for other customers there are up to 20 fields. I got it working by dynamically creating the fields at just the right time in the page lifecycle and going through a lot of headaches.
2 years later, I need to make some pretty big updates to this web form and there are some nifty new technologies. I've worked with ASP.NET Dynamic Data just a bit and, well, I half-crazed plan just occurred to me:
The Ticket object has a one-to-many relationship to ExtendedField, we'll call that relationship Fields for brevity.
Using that, the idea would be to create a FieldTemplate that dynamically generated the list of fields and displayed it.
The big questions here would probably be:
1) Can a single field template resolve to multiple web controls without breaking things?
2) Can dynamic data handle updating/inserting multiple rows in such a fashion?
3) There was a third question I had a few minutes ago, but coworkers interrupted me and I forgot. So now the third question is: what is the third question?
So basically, does this sound like it could work or am I missing a better/more obvious solution?
Did you try creating a FieldTemplate that had a "ListView" of all the Fields? (the ListView would use Dynamic Data to determine which FieldTemplate to display for each field.)
I don't see why this would not be possible. Although, "out of the box", you may have to hit "edit" on each row of the new FieldTemplate's ListView to edit the values. It would be like replacing the "Order Details" link in the Orders List, with an inline List of the "Order Details".
1.) Not very nicely. Can you imagine showing a DateTime, Integers, Phone numbers, Urls, etc with just ONE user control, like text.ascx? Why not have multiple field templates and use UIHint to specify usage per column?
2.) Yes.
3.) Define basically?
regarding one to many relationships, you might have a look at the ListDetails.aspx Page Template in Dynamic Data. Hope this helps.