We just got AEM 6.1, and went through developer training, as well. I am coming from another CMS background (Sharepoint) and wanted to learn / know, if i need to create a list to store data into it, and refer that programatically, somewhere on the page or other common libraries in my project , how do i do that and where do i store the data , is that in the /etc folder. Not clear, I guess, what i learnt from the training is that data is stored in node types as Key / Value pair, so for example if i had a list of movies that with attributes such as date released, actors, awards etc. how do i store that information in AEM, i don't want to store this as a part of the list component of the page. let me know if my question is vague, as i said, i am transitioning form another CMS. Thanks in advance.
I would also appreciate any pointers to blogs, etc..
#Rahul
Where to store data? Data can be stored in both the /etc folder and /content folder. Folders in /etc are usually used to supplement the application's business logic code development, for eg. clientlibs folder is used to store client side code(website styling, scripts etc. The content folder is where the authored content, user generated content gets persisted as key value pairs and you will have to build a logic using jcr api's to retrieve this data from content nodes. You usually use core java to build this logic, if you want data from multiple nodes you can loop through the nodes and populate a data structure with the content, if you require data from a single node you can retrieve it to a variable, it is all upto the programmer and the business scenario involved.
Here is an article which describes how to access content from CQ. https://helpx.adobe.com/experience-manager/using/programmatically-accessing-cq-content-using.html
Related
I have a very specific use case for AEM so maybe you have a solution or an alternative.
I'd need to be able to store the html version of the page in JCR (as it is stored in the dispatcher) so that I would be able to retrieve it in a separate API call from a different system.
Have you had this problem before, or do you have any idea how that could be achieved?
Many thanks
I would strongly suggest not to have the .html page stored inside the AEM instance as that is not core objectives of the AEM as content management system. You should use your dispatcher instance (cached files) and try to keep it on an FTP server and share the file URL with different instances as a data.
Again, please note that AEM instances are very sensitive and should mainly focus on the pages/components. In this case, you are storing the page which is generated out of the components and every time when they generated or modified you need to update this again. it will be a burden. Hence, I am suggesting to take it from the dispatcher instance which will happen as part of the publishing process.
Let me know if you have any other thoughts.
I am currently looking at various i18n npm packages and most seem to insist that the translations are stored in a flat file, e.g. .json formatted file. My questions is whether this has a performance overhead that would be greater then storing the languages in a database, e.g. MongoDB.
For example, if I have 10,000 translations (we will assume that in this particular application only one language file will be needed at a time, i.e. most will be using the application in English and some users may want to set the application to use a different language.) then this will equate to approximately 200kb of data to download before the application can even start being used.
In a React application, a suggested design pattern is to load data using container components, that then pass data to 'dumb' child components. So, would it not make sense to also load translations in the same manner, i.e. group the translations into usage, or by component, so that the data is sent down the wire only when needed, say, from a call to MongoDB?
I would integrate it in your API. That means you can create e.g. a REST or GraphQL API, which handles this for you. In i18n, it is often reasonable to store the data in a hierarchy. This means you can split your translations in different categories (like pages) and simply request those translations, which you really need.
I really like the way of doing it in the react-starter-kit. In this example, you find how they handle it with a GraphQL API and only request those translations, which are really required for rendering the page. Hope this helps.
Important files of the i18n implementation of the react-starter-kit:
GraphQL Query: https://github.com/kriasoft/react-starter-kit/blob/feature/react-intl/src/data/queries/intl.js
Example component implementation: https://github.com/kriasoft/react-starter-kit/blob/feature/react-intl/src/components/Header/Header.js
Of course if you have this amount of translations, I would use a database for a better system usage (in the react starter kit, they use simple file storage which is not really usable with so many translations). A mongodb would be there my first choice, but maybe this is only my own preference of flexibility and own knowledge.
Obviously, you don't want each and every language to be loaded on the client. My understanding of the pattern you described is to use a container component to load the relevant language for the whole app on startup.
When a user switches language, your container will load the relevant language file from the server.
This should work just fine for a small/medium app but has a drawback : you'll need another request to the server after the JS code has loaded to load the i18n data.
Another way to solve this is to use code splitting (and possibly server side rendering) techniques which could allow this workflow :
Server builds a small bundle containing a portion of the i18n data
Client loads the rest of your app code and associated i18n data on demand, as the user navigates through your app
If not yet done having a look at https://react.i18next.com/ might be a good advice. It is based on i18next: learn once - translate everywhere.
Your code will look something like:
<div>{t('simpleContent')}</div>
<Trans i18nKey="userMessagesUnread" count={count}>
Hello <strong title={t('nameTitle')}>{{name}}</strong>, you have {{count}} unread message. <Link to="/msgs">Go to messages</Link>.
</Trans>
Comes with samples for:
- webpack
- cra
- expo.js
- next.js
- storybook integration
- razzle
- dat
- ...
https://github.com/i18next/react-i18next/tree/master/example
Beside that you should also consider workflow during development and later for your translators -> https://www.youtube.com/watch?v=9NOzJhgmyQE
I'm developing a custom module that has to send some information to a Web Service after a Product is inserted, updated or deleted.
In order to ensure that all the fields required by the Web Service exist, I have decided that the module should be the one in charge to put them in the Product form. I achieved It by extending the commerce_product_product_form function.
But now, I have noticed that the values for the fields that I have added are not saved, so I supposed that I have to define a custom table in the module to store the additional information.
I have taken the example from AutoSKU regarding how to save and load data for Product Types form. But, what I've not found is how to do, or what are the hooks for saving and loading data for the Product form.
So, my questions are:
Is It correct what I'm thinking about creating a new table for storing the additional information that I require or can It be implemented as part of the existent routines that the commerce module handles?
If the module has to save and load the data by using a custom table, What are the hooks that I should use in order to append the form data and save It to the module tables?
If I can store the information using the commerce routines, What should be the way and/or the hooks to define the custom form fieds?
Can you tell me if there is any example about how to achieve this?, I have seen some modules but, basically all of them just modified a behavior of the existent fields, they don't add new fields, as far as I could see. The modules that I have reviewed are:
commerce_custom_product
commerce_dressing_room
commerce_fancy_attributes
commerce_tickets
I would like to achieve this by using the commerce and Drupal best practices but I need to finish this module as soon as possible. So, in the meanwhile I'll be saving the data to a custom table and loading the additional information in the commerce_product_product_form hook and saving the information in the commerce_product_save hook.
For loading the data I have tried with the hook_commerce_product_load and hook_entity_load, but for some reason the call seems never happening (I'm sending some information to Watch Dog but It's never displayed), I also have tried by clearing the cache without any change.
Any help would be appreciate.
Thanks in advanced
Are these fields going to be created during normal use of the application (hourly/daily)? Or are they only being added at the beginning (initialization process)?
If the latter, you could create an install script similar to the ones found with many, many modules out there (module-name.install).
Have you considered adding the fields to the content type?
I am developing an iPhone application that has a large database of items which the user can mark as favorite or add to certain lists.
Currently, the SQLite file is first copied from the bundle to the document directory to make it writable and used as a Core Data persistent store. However, I will run into problems when I need to deploy an application update down the track to add extra data or fix minor errors, where the user data will be lost or the application data needs to be synchronised.
After some research I found that perhaps I could add the application data as a read-only persistent store in the bundle and add a second writable persistent store to the documents directory for user data - Core Data would combine the data for me. But then I came across this in the documentation:
When you add stores, you specify the different store attributes by
configuration. When you are creating your configurations, though, remember
that you cannot create cross-store relationships.
I presume that means that I will not be able to maintain relationships between items and lists or items and a 'favorite' record. I guess I could go to the extra effort of traversing the relationship manually. Has anyone had experience with this?
Core Data provides an architecture to support versioning of managed object models and migration of data from one version to another. If your changes to the model are pretty simple, you can use "lightweight migrations", which are pretty easy.
Read more in Apple's documentation here: http://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/CoreDataVersioning/Introduction/Introduction.html
I’m an experienced developer, but new to Mac. I just don’t want to go down one path only to find out that I made some fundamental error or incorrect assumption later on.
I want to ultimately build and sell an iPhone app using Core Data. The app will be free with content available through in-app purchase. Here is what I want to be able to do:
OPTION 1
Build a Mac OS X utility app that points to the same Core Data object model, but has its own “master” database.
Populate the master database using the Mac app.
Export a subset of the master data from the Mac app to a flat file (XML?) that is a subset of the master data.
When the user purchases that data, download from the cloud and import that data into the local iPhone data store.
Number 2 should be easy enough. I have read about the XML Parser that should help me with #4. I need help with #1 and 3.
For #1, I can’t figure out how I can maintain one object model for both apps with Xcode. That data model must accept model versioning. Do I just create two Projects, one Mac and one iPhone, and point them both to the same .xcdatamodel file and the magic happens for me?
For #3, is there any sample code that someone can share that will iterate through an array of objects to create the XML?
OPTION 2
Another option I am considering was discussed below. Instead of worrying about import/export, simply create individual sql files for each set of new or updated data.
I could maintain a separate "metadata" database that has information about the individual sql files that are available to the app.
Then, I can dynamically access the individual SQL files from the local documents directory. This is similar to an iBooks model where the sql files equate to individual books.
I'm thinking I could have only two active database connections at a time... one for the metadata and the other for the specific "book". I am not sure if this will scale to many (tens or hundreds) sql files, however.
Any help is appreciated!
Jon
UPDATE: I just saw the answer from Marcus Zarra at:
Removing and adding persistent stores to a core data application
It sounds like Option 2 is a bad idea.
For (1), you can use the same object model in both apps. Indeed, if you use the same Core Data generated store, you are required to do so. Simply, include the same model file in both apps. In Xcode, the easiest way to do this is to put the model file external to the project folders of each project and then add the model file without copying it to the project folder. This will ensure that both apps use the same model file for every build.
For (3), you need to first create an "export" persistent store using the same model as the reference store and add it to the reference context. In the model, create an "Export" configuration. Create a subentity for every entity in the model but do not change any attributes or relationships. Assign those entities to the Export configuration.
You will need to add a "Clone" method to each ManagedObject subclass for the reference entities. When triggered, the method will return a subentity populated with the reference objects attributes and relationships (the relationship objects will be cloned as well.)
Be aware that cloning an object graph is recursive and can use a lot of memory.
When you save, because you assigned them to the "Export" configuration, all the cloned export entities and their relationships will be saved to the export store. You will have cloned not only the objects but the related object graph.
Include the model and the export store in the iPhone app. Write the app to make use of the export entities only. It will never notice the absence of any reference objects.
For (4), I wouldn't mess around with using XML or exporting the data outside of core data at all. I would just use the export Core Data SQL store created in (3) and be done with it.
You can give a NSManagedObjectContext instance and instance of NSPersistentStoreCoordinator. This class has options allowing you to specify a file location for sotring data and a format (SQLite, Binary, or XML)
How do you plan to actually transfer data from Mac to iPhone? Is this something you do during development, or something people do during daily use? If the latter, you are probably better off building decoupled export/import into your app right away. So the Mac would serialize data into XML or JSON, push it somewhere in the cloud (not sure if local network/bonjour transfer is easier or useful, cloud is more universal), and iPhone fetches the data and deserializes it into the local schema/repository. You should not plan to work on the SQL layer with Core Data. Different platforms may use a different storage backend.