I am evaluating HippoCMS and am trying to model a schema of Venues. I want to model a document that has non-translatable features such as telephoneNumber and emailAddress, plus translatable features such as description.
How do I model this in HippoCMS? How do I ensure that the non-translated fields are shared between the different translations, to avoid each translated document having its own copy of a value. Obviously no matter which language you are reading a site in, the telephoneNumber shouldn't change.
The only way I have found for the moment is to create a document called Venue and another document called VenueTranslation. Venue would contain the telephoneNumber and VenueTranslation would contain its description and a link back to the Venue document. There would then be VenueTranslation documents for each language.
Is this the correct approach?
That could work, but you will run into usability issues. I'd say it depends on how many venues you plan to enter into the system, how many languages you are targeting, and, in the end, how keen are your CMS users to pick the right Venue document for every VenueTranslation corresponding to a language. I can see how this will quickly become error prone and cumbersome, but I don't have the numbers.
Regarding the final question, it's not correct nor incorrect: it's just that since the granularity of the translations in Hippo is at the document level and not at the field level, you have to do it this way. Your model makes sense but is not well supported in the CMS. This use case is trivial in a CMS that supports the notion of translatable field.
Related
I am looking for the most straightaway solution and breaking my head about implementing a bilingual Product model with only one basic requirements: the product query should only deliver results where the product name in the app()->locale language is set.
I'm stuck right at the beginning to decide wether I should keep completely different models (Product_en and Product_es), this would make querying easiest I guess, or have just one Product model with the English texts, with hasOne() methods pointing to the Spanish translations? In the latter case, how would I effectively query for entries which have translations?
Thanks a lot for any hints. Cheers.
I would create a language property for the Product model and would add a Scope for this, where you can filter the results with the value of App::getLocale().
This way, any time you just query the product, you get the Product models on the actually selected language.
How should one structure validation, preparation and arrangement (etc) of data before dealing with the DB?
The data I expect to be passed might need to be validated (ex: category books actually exists) or contain conditional values (ex: sale price should only be set if ad = sale) or values that must be converted to ids (ex: category books must be converted to category_id 123).
I imagine that there are numerous ways to go about this like clumping everything together, grouping by field (do validation, prep etc together per field) or separating by action (validation, prep, etc) and field.
Are there any concepts when it comes to this topic just like the concept of MVC exists? Achieving flexibility, ease of maintenance or something like that?
Anything relating to common used components of model?
(I'm not sure if it helps but I'm currently using CodeIgniter / PHP)
In codeigniter, you can use the Form_Validation class with a callback method that you create. http://codeigniter.com/user_guide/libraries/form_validation.html#callbacks.
In your callback method you can check to see if things exist in database, etc.
I'm talking about HUGE forms - like medical forms with 1000+ fields.
How do you logically create models for them? Do you include every single little field as seperate model? Do you have the whole form as a HUGE model with every single field? Do you have formsections as models and each formsection has few fields?
I know this might be subjective, but I really want some advice on someone who has dealt with this before and save others a lot of time down the road by avoiding mistakes at the onset.
Your data model should follow an EAV method. Medical systems are well suited to this approach as not all patients are going to have all this information filled in. This method allows you to fill in what is appropriate and populate your model. Makes organizing the data easier as well.
As for organizing it in the view, I suggest you break it up into sections where sections are logically related to each other (past history, family history or by type of information), making the information easier to digest.
I have an e-commerce website where it is necessary to make a number of associations e.g. a product needs a category, manufacturer, associated products, etc.
When there is only a fairly small, limited amount of data e.g. Manufacturer I simple use a drop down or option boxes for the user to pick the relevent field / fields.
However for items such as associated products, where I have thousands or products it is not viable to use one of these methods. At the moment I use a searchable / paged table that the user then clicks a button to add the association, this works, but it is pretty time consuming for the user and not what I would consider an ideal solution to the problem.
Has anyone implemented a solution to this problem or could they offer any advice as to how they would come at this from a UI standpoint?
Thanks for any help you can be
The solutions I can think of are:
Auto-complete
Recent associations
Smart associations
There may be more depending on exactly what you're doing, so feel free to add more details or screenshots and I'll think on it more.
Auto-complete
Using an auto-complete field would speed up the process for your users since they wouldn't have to hunt through the table for the association. Rather they could just start typing and have a suggest box appear below the field that allowed them to select what they're looking for.
If you matched your auto-complete on several key fields (i.e. manufacturer and product name), there's a pretty good chance that the user would be able to find the association quickly.
You could also code the suggestion box in such a way that it showed multiple pieces of key data. That way if the user wasn't quite sure what they were looking for, typing a few characters in the field would give them an idea of what they could search with.
Recent Associations
Below your auto-complete field, you could add the 5 to 10 most recent associations that had been made. That would allow your users to quickly add many products to the same association without having to use the auto-complete each time.
Smart Associations
Separate from the above two mechanisms, a smart association is something I first saw when theming a Shopify store. They allow you to automatically create associations based on the products key fields by defining conditions to include or exclude products:
Create Association 'Pants'
Where product title contains string 'pants' or
Where product title contains string 'capri'
The above is controlled by a set of dropdowns and textfields and got around the pain of manually creating associations.
I am new to Core Data, and am designing a schema. I would like to to comment things like:
This what the field name means, and this is what it should contain
Here is why we have this relationship
This integer corresponds to this enum
this field is in this encoding, or can only contain [a-zA-Z0-9-]
I've read over the Xcode Entity Modeling Tools for Core Data articles, and it appears that you can not add any sort of comments, either to the diagram or on a per-attribute basis. How do you document your schema?
Unfortunately, there is no equivalent of annotations on the xcdatamodel document or comment fields associated with entities/attributes/relationships. In our shop, we have a separate document (an outliner works well) for annotating/commenting on xcdatamodels. Descriptive attribute/relationship names often goes a long way just on its own.
In terms of documenting constraints (e.g. "this field can only contain [a-zA-Z0-9-]"), that can be encoded in validation methods for the custom objects associated with an entity.