Jump to content

FieldtypeMeasurement


MarkE
 Share

Recommended Posts

This fieldtype and inputfield bundle was built for storing measurement values within a field, rendering them in a variety of formats and converting them to other units or otherwise modifying them via the API.

The API consists of a number of predefined functions, some of which include...

  • render() for rendering the measurement object,
  • valueAs() for converting the value to another unit value,
  • convertTo() for converting the whole measurement object to different units, and
  • add() and subtract() for for modifying the stored value by the value (converted as required) in another measurement.

In the admin the inputfield includes a checkbox (which can be optionally disabled) for converting values on page save. For an example if a value was typed in as centimeters, the unit was changed to metres, and the page saved with this checkbox selected, said value would be automatically converted so that e.g. 170 cm becomes 1.7 m.

measurement-fieldtype-for-processwire.jp

A simple length field using Fieldtype Measurement and Inputfield Measurement.

Combination units (e.g. feet and inches) are also supported.

Please note that this module is 'proof of concept' at the moment - there are limited units available and quite a lot of code tidying to do. More units will be added shortly.

See the GitHub at https://github.com/MetaTunes/FieldtypeMeasurement for full details and updates.

Edited by MarkE
Modified operation of add() & subtract()
  • Like 6
Link to comment
Share on other sites

Thanks for this contribution @MarkE,

  1. Is there a reason you combine magnitudes into pipe-separated values? This makes it difficult to query. For example, what if I wanted to find values whose magnitude were > 10? Storing these pipe-separated strings make this tricky. I have only quickly looked at the code so you could have already figured this out.
  2. Combination units: I think I get the idea for this (e.g. the feet and inches). From an UX/UI point of view though, maybe it is prone to errors? Editors need to remember to input a pipe as well as remember what side of the pipe is what measurement. Maybe this is an exaggeration, as it is quite easy to remember feet|inches but what if it is another not-so-obvious combination?

The auto-conversation feature looks cool though 😀.

Link to comment
Share on other sites

Thanks for the comments @kongondo. As stated, it is POC at the moment so I am very open to suggestions for improvements 🙂 . I have built it with an app in mind, but I wanted to do the fieldtype before proceeding with the app. No doubt using it in anger will result in some changes.

4 minutes ago, kongondo said:

Is there a reason you combine magnitudes into pipe-separated values?

I combined the magnitudes as pipe-separated in order to store them as a string in the DB. I am having second thoughts about this. In fact I am wondering about using arrays and then storing a json in the DB.

At the moment, the queries don't work with combi fields, but there is a wider issue: if there are a mix of units in the field instances then numerical comparisons are meaningless. Therefore it is necessary to loop through the pages with measurements and convertTo() a common unit, then compare - this deals with combi units at the same time (assuming the common unit is single-valued!). I'm therefore thinking how could I solve that wider problem at the same time as the one you mention?

5 minutes ago, kongondo said:

maybe it is prone to errors? Editors need to remember to input a pipe as well as remember what side of the pipe is what measurement.

Fair point. There is some error checking at the moment, but I still need to catch the exceptions which are generated and provide helpful messages. Hopefully the dropdown indicates the format and editors will soon get the hang of this. Again, I am open to better suggestions - it needs a balance between conciseness and idiocy-proof.

Link to comment
Share on other sites

20 minutes ago, MarkE said:

I combined the magnitudes as pipe-separated in order to store them as a string in the DB. I am having second thoughts about this. In fact I am wondering about using arrays and then storing a json in the DB.

Clarification: The above is a slight red herring regarding the isue raised as the multi-values are actually stored in the object as an array. The pipe format is just for the UI and the SQL DB.

Link to comment
Share on other sites

1 hour ago, MarkE said:

I'm therefore thinking how could I solve that wider problem at the same time as the one you mention?

I have learnt (sometimes the hard way) that mixing values  or data types in the database for the sake of UI/UX is never a good a idea. Modelling a real world problem is many times not straightforward. Reading up on DB normalisation helped clarify things for me. Before I design any DB model / schema I ask myself two basic questions:

  1. Will users need to query the data? (e.g. searches, selector)
  2. Will the data require manipulations at the DB level? 

If the answer to any of these questions is YES, I throw out any notions of storing data as JSON. In 90+% of the time this will be the case. The data will need to be queryable. In fact, I rarely store anything as JSON (even with the not-so-recent MySQL JSON-capabilities - the pros and cons of which are a debate for another day, btw). The only thing I store as JSON are things like site settings, data points of a map for a chart, etc., as these don't need querying or direct computation applied on them. In this Fieldtype's case, I would steer away from JSON. The name of the field itself implies mathematical computation will be involved. I would use a DECIMAL data type to store the quantifiable values. You will then be faced with the age-old question of whether to expand horizontally (add more columns to accommodate more combinations of feet|inches- i.e. regular relational design) or expand vertically (add more rows - i.e., Entity Attribute Value [EAV]). Each of these have their pros and cons. 

1 hour ago, MarkE said:

but there is a wider issue: if there are a mix of units in the field instances then numerical comparisons are meaningless. Therefore it is necessary to loop through the pages with measurements and convertTo() a common unit, then compare - this deals with combi units at the same time (assuming the common unit is single-valued!). I'm therefore thinking how could I solve that wider problem at the same time as the one you mention?

Probably one way to do this is to try and ensure that you are comparing apples to apples at the DB-level. You can decide on a base unit that will be used to store all measurement values. For instance, centimetres. In the UI, the users will always see their measurements in the selected unit (feet, inches, etc). You can already see the problem with this 😁.  It requires knowledge of the type of measurement that is being stored, e.g. length, volume, area, etc! Does it mean you will have a base unit for all these groups of measurements? What about custom measurements that don't readily fit into one of these paradigms? I am probably overthinking this. Or I have been working on Padloper for too long 😁.

1 hour ago, MarkE said:

I have built it with an app in mind, but I wanted to do the fieldtype before proceeding with the app.

Good decision. I think it is 'easier' to bend the UI/UX to fit your DB model than the other way around.

Sorry, I don't have much answers at the moment but hopefully this helps generate a meaningful discussion. 

Link to comment
Share on other sites

19 minutes ago, kongondo said:

You can decide on a base unit that will be used to store all measurement values. For instance, centimetres. In the UI

This was my original approach, which I changed for a reason I can’t recall 🤔. I’ll reconsider. 
 

Edit: I think the reason was that the base unit definition might change. However, now I’ve got more mileage under my belt with this, I might be able to solve that problem. 

Edited by MarkE
Afterthought
Link to comment
Share on other sites

v0.0.3 saves database value in terms of base units. Selector fieldname.magnitude then operates consistently regardless of what units are chosen - selecting values in terms of base units. Thanks for the tip @kongondo

  • Like 3
Link to comment
Share on other sites

Apologies for some bugs introduced in 0.0.3. (Note to self: don't release code late at night). Hopefully all fixed in 0.0.4 which also adds a new static function FieldtypeMeasurement::addMeasurements()

Link to comment
Share on other sites

  • 3 weeks later...

I've put quite a lot of work into this now. There are lots of additional units added plus a greatly extended API. This enhances the formatting capability and introduces 'dimensional analysis'. So it is now possible to (say) multiply measurements and properly interpret the results. - e.g (as a simple example) speed x time = distance

$speed = new Measurement('Speed', 'furlong per fortnight', 20);
$time = new Measurement('Time', 'hour', 3);
$length = $speed->multiplyBy($time, 'Length', 'yard');
d($length->render(['decimals' =>2]));

Result is '39.29yd'

Omitting the 'Length', 'yard' specification means that the result is returned in base units for the first compatible quantity for the computed dimension:

$length = $speed->multiplyBy($time);
d($length->render(['decimals' =>2]));

Result is '35.92m'

See https://github.com/MetaTunes/FieldtypeMeasurement for full details.

The module is still alpha, so use in production systems is not advised. However, the functionality is now pretty complete but I have a bit of tidying up to do - and some more extensive testing in a new app. New units will probably also be added (but users can add their own anyway).

Try it out and let me know of any issues or suggestions 🙂 

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Similar Content

    • By monollonom
      PageMjmlToHtml
      Github: https://github.com/romaincazier/PageMjmlToHtml
      Modules directory: https://processwire.com/modules/page-mjml-to-html/ (pending approval)
      A module allowing you to write your Processwire template using MJML and get a converted HTML output using MJML API.
      This is considered to be in alpha and as such needs some testing before being used in production!

      About
      Created by Mailjet, MJML is a markup language making it a breeze to create newsletters displayed consistently across all email clients.
      Write your template using MJML combined with Processwire’s API and this module will automatically convert your code into a working newsletter thanks to their free-to-use Rest API.
      Prerequisite
      For this module to work you will need to get an API key and paste it in the module’s configuration.
      Usage
      Once your credentials are validated, select the template(s) in which you’re using the MJML syntax, save and go visualize your page(s) to see if everything’s good. You will either get error/warning messages or your email properly formatted and ready-to-go.
      From there you can copy/paste the raw generated code in an external mailing service or distribute your newsletter using ProMailer.
      Features
      The MJML output is cached to avoid repetitive API calls Not cached if there are errors/warnings Cleared if the page is saved Cleared if the template file has been modified A simple (dumb?) code viewer highlights lines with errors/warnings A button is added to quickly copy the raw code of the generated newsletter Not added if the page is rendered outside of a PageView Only visible to users with the page’s edit permission A shortcut is also added under “View” in the edit page to open the raw code in a new tab Multi-languages support
      Notes
      The code viewer is only shown to superusers. If there’s an error the page will display:
      Only its title for guests Its title and a message inviting to contact the administrator for editors If you are using the markup regions output strategy, it might be best to not append files to preserve your MJML markup before calling the MJML API. This option is available in the module’s settings.
    • By Marco Ro
      Hi guys!
      I'm a bit anxious because this is the first module I present! (beta modulo) But I will finally be able to share something with the community too! :)
      This is a BETA version of the PayPal payment system called: PayPal Commerce Platform.
      It is an advanced system (Business Pro account is needed) that brings various benefits in terms of fees and above all integrates direct payment with credit/debit cards. 
      The module integrates with Padloper 0.0.2, which is the current installation I'm using.
      This system integrates the classic PayPal buy button, the alternative or local payment method and the new payment system: credit/debit cards that doesn't go through the PayPal account. It is a Stripe-style payment, it connects directly with the bank and integrates 3D security validation.
      I say that it is a BETA because this module currently only works with Sandbox account, to put it live you need to change API url manually (manually for the moment).
      Because this module is not ready for live:
      I would like to have your opinion on how I built the module (is the first one I do). I don't want to share something that is not fish but I need a comparison with someone more experienced than me, for be sure that this is the best way to code the module.
      If you want to try this I created a git, you will find all the instructions for installation and correct operation. (Git has a MIT licensed)
      https://github.com/MarcooRo/processwire-PayPal-Commerce-Platform I hope I did something that you guys can like :)
    • By monollonom
      (once again I was surprised to see a work of mine pop up in the newsletter, this time without even listing the module on PW modules website 😅. Thx @teppo !)
      FieldtypeQRCode
      Github: https://github.com/romaincazier/FieldtypeQRCode
      Modules directory: https://processwire.com/modules/fieldtype-qrcode/
      A simple fieldtype generating a QR Code from the public URL of the page, and more.
      Using the PHP library QR Code Generator by Kazuhiko Arase.

      Options
      In the field’s Details tab you can change between .gif or .svg formats. If you select .svg you will have the option to directly output the markup instead of a base64 image. SVG is the default.
      You can also change what is used to generate the QR code and even have several sources. The accepted sources (separated by a comma) are: httpUrl, editUrl, or the name of any text/URL/file/image field.
      If LanguageSupport is installed the compatible sources (httpUrl, text field, ...) will return as many QR codes as there are languages. Note however that when outputting on the front-end, only the languages visible to the user will be generated.
      Formatting
      Unformatted value
      When using $page->getUnformatted("qrcode_field") it returns an array with the following structure:
      [ [ "label" => string, // label used in the admin "qr" => string, // the qrcode image "source" => string, // the source, as defined in the configuration "text" => string // and the text used to generate the qrcode ], ... ] Formatted value
      The formatted value is an <img>/<svg> (or several right next to each other). There is no other markup.
      Should you need the same markup as in the admin you could use:
      $field = $fields->get("qrcode_field"); $field->type->markupValue($page, $field, $page->getUnformatted("qrcode_field")); But it’s a bit cumbersome, plus you need to import the FieldtypeQRCode's css/js. Best is to make your own markup using the unformatted value.
      Static QR code generator
      You can call FieldtypeQRCode::generateQRCode to generate any QR code you want. Its arguments are:
      string $text bool $svg Generate the QR code as svg instead of gif ? (default=true) bool $markup If svg, output its markup instead of a base64 ? (default=false) Hooks
      Please have a look at the source code for more details about the hookable functions.
      Examples
      $wire->addHookAfter("FieldtypeQRCode::getQRText", function($event) { $page = $event->arguments("page"); $event->return = $page->title; // or could be: $event->return = "Your custom text"; }) $wire->addHookAfter("FieldtypeQRCode::generateQRCodes", function($event) { $qrcodes = $event->return; // keep everything except the QR codes generated from editUrl foreach($qrcodes as $key => &$qrcode) { if($qrcode["source"] === "editUrl") { unset($qrcodes[$key]); } } unset($qrcode); $event->return = $qrcodes; })
    • By Sebi
      AppApiFile adds the /file endpoint to the AppApi routes definition. Makes it possible to query files via the api. 
      This module relies on the base module AppApi, which must be installed before AppApiFile can do its work.
      Features
      You can access all files that are uploaded at any ProcessWire page. Call api/file/route/in/pagetree?file=test.jpg to access a page via its route in the page tree. Alternatively you can call api/file/4242?file=test.jpg (e.g.,) to access a page by its id. The module will make sure that the page is accessible by the active user.
      The GET-param "file" defines the basename of the file which you want to get.
      The following GET-params (optional) can be used to manipulate an image:
      width height maxwidth maxheight cropX cropY Use GET-Param format=base64 to receive the file in base64 format.
    • By tcnet
      File Manager for ProcessWire is a module to manager files and folders from the CMS backend. It supports creating, deleting, renaming, packing, unpacking, uploading, downloading and editing of files and folders. The integrated code editor ACE supports highlighting of all common programming languages.
      https://github.com/techcnet/ProcessFileManager

      Warning
      This module is probably the most powerful module. You might destroy your processwire installation if you don't exactly know what you doing. Be careful and use it at your own risk!
      ACE code editor
      This module uses ACE code editor available from: https://github.com/ajaxorg/ace

      Dragscroll
      This module uses the JavaScript dragscroll available from: http://github.com/asvd/dragscroll. Dragscroll adds the ability to drag the table horizontally with the mouse pointer.
      PHP File Manager
      This module uses a modified version of PHP File Manager available from: https://github.com/alexantr/filemanager
       
×
×
  • Create New...