Jump to content

MarkE

Members
  • Posts

    459
  • Joined

  • Last visited

  • Days Won

    6

MarkE last won the day on October 17

MarkE had the most liked content!

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

MarkE's Achievements

Sr. Member

Sr. Member (5/6)

190

Reputation

  1. Found it! $pageArray = $pages->find("template=basic-page, length.magnitude>0, include=all"); $lengths = $pageArray->each(function($p) {$p->of(false);})->each('length'); I hadn't originally thought about chaining eaches, but of course that is possible if the result is a wire array.
  2. I have a selector: $pageArray = $pages->find("template=basic-page, length.magnitude>0, include=all"); I would like an array of each of the 'length' fields. However, the field is an object and $pageArray->each('length') returns the formatted values; I want the unformatted objects. I thought perhaps I could use a callable like: $pageArray = $pages->find("template=basic-page, length.magnitude>0, include=all"); $lengths = $pageArray->each(function($p) { $length = $p->getUnformatted('length'); return $length; }); but it seems that only strings can be returned and those are concatenated. So it looks like I have to use a foreach() loop - which works, but I was expecting some neater shorthand. Any thoughts?
  3. 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()
  4. 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
  5. 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.
  6. 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.
  7. 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. 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? 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.
  8. OK - I did this and it seems to work OK. @teppowas rather quick off the mark with the PW weekly report - I still have to add a lot of units and do some tidying (and remove debugging lines in case people don't have Tracy!). I will also add some notes about what I learnt doing this as the existing tutorials (such as @bernhard's) don't seem to cover fieldtypes which use the database. Support thread started at
  9. 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. 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.
  10. Not sure this is strictly a shared server issue. I find that I want to update data structures and settings pages, but don’t want to overwrite user-updated pages so database backup and restore (or phpmyadmin) doesn’t work. That’s why I wrote ProcessDbMigrate - still in alpha but usable provided everything is tested first. Or, if you prefer to do it all in code with the api, rather than in UI, there is RockMigrations.
  11. I found a few more small bugs and have also greatly enhanced the help file, so that it is now available as a pop-out when working in the module. The new version (0.1.3) is at https://github.com/MetaTunes/ProcessDbMigrate. You should be able to replace the files in your ProcessDbMigrate directory with the new ones and 'refresh modules' to upgrade. @cjx2240, @antpreand @dotnetic (and anyone else): I'd appreciate your feedback as I am considering releasing this (as alpha) to the modules directory.
  12. Thanks @bernhard. I’ve not really built a fieldtype module before. I’ve mod’d @Robin S’s RuntimeOnly and I’ve read your tutorial, but that still leaves quite a few knowledge gaps. I’ll give it a go, but may be back with more questions 🤔
  13. I've been looking around for a fieldtype that can handle weights and measures but, rather surprisingly, can't seem to find anything. What I have in mind is a field that essentially comprises 2 elements - a (float) value and a (dropdown) measure (e.g. lbs, kg). It would also have an associated standard unit (usually an SI unit, I guess), which might or might not be in the dropdown, and each measure option would have a conversion factor to the standard unit. The value would be stored in the database as standard units. The measure options, standard unit and conversions would be specified in the input/details for the field, along with a default measurement option; these could also be set via API. If a user changes the measurement option in the dropdown, then the value would be amended accordingly (via AJAX). Is it possible to use the Combo ProField for this pupose (I don't have ProFields)? Would it be desirable to build a new Fieldtype module for this? Or is there a better way of achieving the same end?
  14. Just a thought. Could you use $config->js() or $config->jsConfig() to set the field name having the focus and then have the js in admin.js defaulting to title if required?
  15. Thanks for the comments @cjx2240. Sorry it has taken so long to reply. I have done quite a bit of work removing various bugs (there were quite a few!). I have also extended the functionality considerably to include a database comparison feature (allows draft migrations to be created based on database differences). There is also the capability to run custom code alongside the migration via hooks. The help file is now (roughly) indexed and available at https://metatunes.github.io/DbMigrate/help.html. The new version (0.1.0) is at https://github.com/MetaTunes/ProcessDbMigrate. You should be able to replace the files in your ProcessDbMigrate directory with the new ones and 'refresh modules' to upgrade. Please let me know if any of the snags you hit have persisted after the update (or any new ones encountered) and I will try and resolve them more quickly next time! I'm hoping that this version is a passable 'alpha' as opposed to the previous 'proof of concept' and will look to submit it to the modules directory if it seems sufficiently robust.
×
×
  • Create New...