Input field for dimensions

[Hieu Do]

Hello,

I need to save product's dimensions (example: a phone has dimensions 5.38" x 2.75" x 0.31") but don't want to use 3 float-number fields. Instead, I want to use a field type that can display 3 input boxes on edit-page screen then store entered values into a single table in database. I don't want to separate them into 3 tables because they're simply unnecessary.

Is it possible to create this kind of field?

Thank you!

[Martijn Geerts]

Dive into Fieldtypes, they handle data storage/cleaning before putting in de db.
Take a look at the mapmarker Fieldtype or soma's range slider. They both have an Inputfield and an own Fieldtype.

[Soma]

Why not just have a text input and enter '5.38" x 2.75" x 0.31"' ?

[Soma]

I just quickly create a new FieldtypeDimension module.

https://github.com/somatonic/FieldtypeDimension

Will later add a thread and to the repository.

Forum Module Thread http://processwire.com/talk/topic/4081-fieldtypedimension/

[Hieu Do]

OMG, thanks so much Soma, much appreciated. I'll try your module when I get home.

I just think why don't we make a fieldtype with arbitrary amount of text fields inside, each text field is a column in a table?

I know the Repeater field is capable for this but it actually contains a link to other fields, thus it has to use JOIN query which I don't desire.

I just want to get all info at once by issuing one SELECT query.

[ryan]

This is exactly what Fieldtypes are designed for: to contain a type of data represented by a table (schema), whether that implies a single field or a whole bunch of them. You can also achieve the same thing more easily by using 3 separate fields in PW, but you are right that it will take more overhead for PW to manage it, and there are UI benefits to having a dedicated Inputfield. However, query counting is usually a waste of time. Unless you are dealing with these items at a massive scale, there is unlikely to be a measurable difference. So when thinking about this stuff you do have to consider what is more worthwhile. In your case, I think a Fieldtype+Inputfield makes more sense, given that you are willing to explore deeper into the code of creating Fieldtypes/Inputfields. But unless you are dealing with hundreds of thousands of pages, I think the greater benefit here is just the dedicated Inputfield aspect. 

[mindplay.dk]

This makes a good "textbook" example of a Fieldtype/Inputfield pair that is easy to understand - maybe this should be referenced in the Wiki?

Question: is it possible to extend this with support for a computed (as opposed to stored) value, such as volume = width * height * depth ... adding the computed value would be easy enough, I suppose - but getting the same name to work in an SQL query via the PW query language, is that possible?

[Soma]

Hey mindplay.dk, yeah good idea. I just added support for volume value that will get calculated once a dimension value has changed. This value also gets saved to the DB.

To add a runtime computed value it's very easy, but unfortunately then it wouldn't be possible to query volume using selectors. Much like the concat fieldtype of Ryan.

[mindplay.dk]

Thank you Soma, this is educational

For a computed value that is a product strictly of values within the same context, physically materializing the computed value works fine - for computed values that are a product of any value outside of that context, that approach doesn't really work.

@Ryan: do you have any plans to open the query language to computed attributes via modules somehow?

To use a different case/example, consider a Currency field - you would need an external table of exchange rates in order to compute prices in the user's currency, say, when searching for products by price range. Because the exchange rates can change, storing the converted prices is a no-go.

In this case, you would need an expression like 'template=product, price.usd < 100', where the 'usd' property is the price-value dynamically converted to US dollars.

You can support $page->price->usd at run-time by exposing the price-value as an object, computing the value in PHP.

But is there any way to define and perform the SQL equivalent of that computation at query-time?

[ryan]

There may be a way to do it from the SQL side, and that would probably be a good use case for using an SQL query rather than a selector. I don't currently have plans to make selectors support that level of query, as it's a pretty rare need (this being the first time it's come up). When a query needs to perform a currency conversion (and this is something I've had to do), I perform the currency conversion first, and then use the converted value in the selector query. That actually reminds me that I have a currency conversion module that I need to finish up and post soon.

[adrian]

Hey Soma,

Just curious why your module only supports integers. I'll probably modify for my needs, but am wondering if there was some reason I am overlooking.

[Soma]

There's maybe. Because I'm lazy and do number_format($page->dimension->width/100, 2).

I'm not really sure, but I never want(ed) to support a setting for float, as my experience with it is mixed and it would mean to make it a lot more complex than I really wanted for a first basic first version. Make it configurable may be possible but I currently have no plans. Also there's endless possibilities and I could also ask why not also support only w&h and volume and area etc Keeping it integer makes it more straight forward. I could also imagine instead consider making a module that does formatting for the field for you, I think it would be more ideal to do the calculation 130/100 on runtime, instead of making a modified version of the field.

[adrian]

I guess my main concern is that dimensions for things are rarely whole numbers (integers), so I am not sure how useful the module can be in its current form. Maybe not an issue in the metric world (where I was born and raised) where you could specify dimensions in millimeters, but now that I live in a backward imperial country (practically, although not officially), and we are stuck with inches as the smallest unit of measurement, it becomes a problem.

I am not completely convinced on these multiple input field types. I have always set up dimensions as three separate fields and done the calculations at runtime (I also don't like the redundancy of storing calculated values), but I was looking for a way to use the volume in a selector and thought this might be a good approach. Makes me wish for the ability to do math and apply other calculations / functions to the items in a query, but you have heard my thoughts on that before

EDIT: Apologies - I just properly read and understood your instructions - you are saying to store as 538 and format on output to 5.38

[arjen]

Great post and great example as usual. Really learning a lot today! I do have one question about the naming. One this, this, this and this line you are using data as width, but for the other fields you are using data_height as height and data_depth as depth. Why didn't you use data_width? Is this necessary for the first item? Or did you just name it that way? Just curious 

[Soma]

'data' is coming and is set from base Fieldtype schema. So reusing/overwriting it.

[arjen]

Thanks!