I'm building a cookery website for a client, who's decided to use ExpressionEngine (not my choice, I did try and opt for something different). One aspect of the website is the ability for logged-in members to add recipes.
So far, I've create a channel for recipes and a channel for ingredients. I've then extended the Member module and create a SAEF with the Safecracker module so logged-in users can add a recipe entry. However, where I'm stuck is trying to create a one-to-many relationships, where a recipe can have many ingredients, and an ingredient can belong to many recipes.
Does ExpressionEngine support this out of the box and I'm missing it? Or does I have to do some hacking? Or am I going over this in completely the wrong manner?
Any help would be greatly appreciated.
Your best bet is to use a 3rd party commercial add-on called Playa ("Playa" being a playful take on 1-to-many relationships). It's from Pixel & Tonic and will do exactly what you need. Their add-ons and support are top-notch.
That way your client will have the feature they need with an optimal interface on both the back end control panel and within the front-end safecracker form. No hacking needed for this and maintainability is much more solid over time as opposed to hacking at EE's core.
Related
As a newbie to Liferay I am investigating whether I used the right approach to populate data forms.
When populating a form with a number of text fields using an external REST service, I alraedy implemented the following approaches:
Creating a web content page and fill it with Ajax. Works, but using Jquery is not my preferred (modern) approach for accessing REST services.
Creating a web page using an Angular/React portlet, etc. Also worked for me. As I understand, per page I have to create a small Angular (module) project.
Creating a Form page that retrieves the fields by a data provider. Worked also for me, but this was presentation only.
"Service builders" are used in the examples for working with databases. I did not use this method yet.
Below are a few questions but there only 1 theme: when using Liferay, what are the beste techniques to populate data forms?
Is there a better/easier approach in Liferay to fill the form?
When using option 3, will it call the data provider multiple times for each field?
What if I would like to post the populated form data to the REST service?
Which approach is best to fill a table with rows of data?
Can/should "service builders" be used for interacting with REST services as well?
Is there a way to interact with basic components and Angular? I could not find anything on the internet yet.
I believe that your question is still out of focus for stackoverflow, as it's asking for "the best" way - to that, the answer is a firm "it depends".
You're listing a couple of options yourself. What you choose will in the end depend on
the technology you know
the technology you feel comfortable maintaining long term
the business requirements - e.g. how flexible to you need to be? can you go low-code, or do you need the full flexibility to develop an actual app
how frontend-heavy are your requirements
how independent of Liferay do you want them to be?
That being said: All of your options are good choices in various situations that you need to solve.
My general recommendation is to think maintenance, and optimize for the future maintenance of your solution, rather than the initial implementation time.
But, unfortunately, no firm single answer.
I am new to share point and still learning all the best practices, but I have a parent site called "Clients" and a sub site for the each of the clients i.e. Walmart, Kmart, Target. Is it a best practice to have a unique document library for each of the sub sites and the parent site. Or to use just one library for all of them. And if I were to use just one how would I set that up?
Thanks
Sites and Pages are not the same!!!
I wish that was more clear. In this case I want a SITE with the customers. Then each customer will have its own page. This way I can use the same apps across all the customers. I will probably need to learn how to create a customer template next.
to start with you need to answer few questions first, and these questions will help you to decide on an approach.
Do you have unique documents per client
will you control access to your users, that is each subsite will have unique permission, users for one client say for instance walmart should not access documents of Kmart
what would be tentative size of each documents and how much will that grow over the year
above are few question which will help you to get started, being said that, I will start creating a site and if the look and feel are the same for my other clients with little changes, then save the site as template.
This template will be my base for other client subsites/ sites.
will also create a global document library, which will store relavant documents which can be sharable across subsites
If required, each client will have their own subsites and own libraries for maintainabilty. this will also help to move subsite to its own site collection if there is hugh growth in data for a particular client.
You can also plan to use search, and webparts like content search query webpart to mashup data from subsites.
Another area to explore is metadata and Information architecture.
When you ask "Is it best practices" for the multiple Libraries or a single Library. From what you have described and Ramakrishnaraja was trying to say, you need to figure out what would work best for the situation. I don't know if you mean to have a different group called "customers" or if that is the same as "Clients" I'm going to respond assuming you mean both parties are the same.
Ramakrishnaraja points out that you have one central log on page "Clients- 'Main'" which leads to the other pages. If you want to the users to be divided into groups that have access only to the documents within their repective page then you should create multiple Document libraries. If you want the users to have access between the sub pages and use/edit files between the sites then best practices would be to have one Library for the Site.
I hope this helps you. Ramakrishnaraja makes a lot of good points and approaches it from a design overview rather than a specific response to your situation so try to use his post from that perspective.
I am still a relative newcomer to Expression Engine as a developer and a user. I am faced with the problem that a lot of my knowledge is being passed to me by users who have found ways to accomplish tasks traditionally undertaken by developers (eg product libraries) by using the channels system.
What I wondered was what people's views are on when it is best to advise a client to use this and when not to.
Let me use an example, a client wants a system which had venues where events could take place. The previous developer had chosen to use the membership system for the venues and the channels system for the events and write some custom code to attempt to knit the two together, specifically because there are not enough hooks to accomplish some background automated tasks like looking up the long/lat of the address of a venue when it is created or updated.
I am picking up after someone else's work largely but its not their fault, it was the information they were given as they were also new to the system.
In any other project this would be a master-detail type setup, events belong to venues, i'd probably write 2 custom tables, editors in the admin area via modules and then use regular custom code in the pages to display and act upon the info - this way, I could control what's happening when a user hits submit.
However, the instigating party is a veteran user of Expression Engine and instructed the previous developer in the manner of "oh, just put it all in the channels and then there's this tag and that tag and so on".
So, am I missing the point or am I right that this does not fit the channels system and when should you use channels and when not?
Thanks friends.
This question is very hypothetical and every developer will give you a different answer as it all depends on the requirement and how that EE developer rolls.
Fundamentally ExpressionEngine allows you to approach builds in many ways, none are right and wrong, albeit some are easier, some harder, others just plain daft.
Basically Channels are groups of data "entries" - these can be anything. Using your example, venues could be one channel with fields created relevant to the subject (e.g. location, size, price, etc). And another channel for events with different fields (e.g. date, type, location).
Mostly anything can be slotted into a channel. But member details are best held within the native member functionality (although there is a commercial add-on that holds member data in a channel).
You reference the previous developers approach - this could be because they used a third-party add-on that required the data to be held separately to channels, or a lack of understanding on best approach. Or just because the developer decided to approach it that way! I suspect the last developer then associated a member (venue) to an entry (event) to link the event to the venue. Basic EE functionality allows for related entries which allows you to associate 1 entry with another (e.g. Event -> Venue), or using the excellent Playa add-on, so this approach is really not necessary.
Personally I would always store the data in channels, and people/members in the native membership functionality (e.g. admin, visitors to the site, customers, etc). I'd only build an add-on (utilising it's own tables/data) to store additional information if it was way outside what EE could store.
To answer your practical question (it's stretching the scope of what Stack Overflow questions are supposed be honestly): you should use a channel for Venues and channel for Events, and the Venue field in the Event entry is a "Related Entries" fieldtype linked to the Venues channel. That's the "standard" EE way, and the most similar to a traditional database schema.
I am a student developer with Oregon State University's Business Solutions Group and I am currently working on a Salesforce integration project for one of the University's colleges. As you can imagine, the data we are working with is coming from several different places and in a variety of different formats. I was wondering if anyone with more experience in setting up Salesforce object schemas could talk about the pros and cons of relational database style normalization in Salesforce. What do we gain by not normalizing and using Record Types to categorize data? (For example: a Person-Account that encompasses Students and Faculty and uses Salesforce Record Types to differentiate between the two) What do we lose?
This message was inspired by this webpage:
Salesforce Guru: Record Types
Notice that the first thing it advises is to not normalize (overmuch) because it prevents us from taking advantage of some built-in Salesforce functionality. Overall, the page seemed helpful, albeit incomplete.
The answer to this question seems critical to the success of our project and will help us to decide how to reorganize the data we are initially migrating to Salesforce and ultimately build our Salesforce object schema, so any thoughts, additional resources or advice are very much appreciated. Thanks!
The inspirational web page is correct. With the "standard objects" like Account, Contact, Case, Lead, etc. and even with custom objects the system works best to use fewer tables (objects) and segregate the data based on some value (such as record type).
By using record types you leverage the point-and-click UI. For example, for the Account object you have a default page layout. But for each record type you can have a unique page layout. Furthermore the security model uses record types to limit or grant access as appropriate to different user profiles.
As the author says SOQL is NOT SQL.
How can I communicate in a very simple and effective way the path the user takes through my application?
I'm currently working in a Ruby and Rails environment, so I tend to visualize my application in terms of RESTful URIs. So for example, if I want my users to sign up, I could match a new route called /users/new. The thing is, I would like to see beyond that specific action, and visualize how many pages or forms does it take to create an account and some business logic associated with the process in general. In other words, I'd like to see a mix of a workflow diagram and some implementation details (at an interface level).
I was thinking in showing mockup pictures wrapped in boxes, and relate them through arrows with their corresponding GET, POST, PUT, DELETE methods and URIs attached to them. I think it is a good idea, but I haven't seen examples yet that inspire me.
In your experience, what helps you see the big picture? Balsamiq mockups allow to define links and navigate through the app, but it doesn't help to conceptualize.
Have you thought of using a mind-map? You could try the free FreeMind
If you stick with UML, you could consider an Activity diagram.
I think you're on the right path. Showing different screens with possible combinations of users' transactions between them is a good technique. Basically you would be able to show user's flow through your application and stress out decisions a user will make on the way.
The good example for it was presented here http://vimeo.com/43869717
This technique called Storyboarding. You should be able to find some examples. But the one I mentioned above is one of the best Storyboarding techniques. I use it all the time to show the big picture and present application workflow from user perspective to my team.