I'm trying to create a blog system using YII. Examples and Tutorials are available. But they use a multi-value table for a Post. Its something like
Post(Id, Title, Content, Author, Tags)
Here there are multiple values (separated by comas) in Tags column. So I created a schema to avoid this and now I have tables like this,
Post(Id, Title, Content, Author)
Tag(Id, Name)
PostHaveTags(Post_Id, Tag_Id)
after normalizing the schema.
I could manage to make a relation in relations() method. But I cannot figure out how to get inputs from a view and validate values of 'tags'. Can anyone help me regarding this please?
Thanx.
You can try to use javascript to allow your forms to grow dynamically and include zero, one or many tags. which you can validate in the model using custom validation rules.
Finally I found the solution. And here is what I did,
First I got the appropriate data from the view and validated them, defining some rules. Then in the afterSave() method I inserted the gathered data into relative relations manually. I don't know whether there is an easy way. But I think, if so, YII will generate the code for us. :)
Thanx guys for helping.
Related
For a bigcommerce site I'm working on we will need to have custom content types or something similar that would accomplish the same goal.
One example is we need a way for the admin to arbitrarily add locations that have the following fields: latitude, longitude, as well as text fields for facts.
I saw that there were ways that you could add ui fields to products
https://developer.bigcommerce.com/stencil-docs/configure-store-design-ui/defining-ui-options
But what I want to create is not a product. I want various types of posts with their own set of fields. Basically the same kind of features I would be able to find in something like Drupal.
Edit: Also I cannot use any outside cms. It can only be the bigcommerce cms alone
I need to get the posts to display on one of my pages...
How to I do this? Can I create the link via the database? I would prefer this if possible as I'm way better at sql than C#
Cheers
There's are two regions you can add to your page type, Posts & Post Models. The first only loads the general information while the second loads the entire post models including all extensions.
Then in your page you get to select which post type, the number of posts, included related entities & sort order for the posts.
You can read about the included standard regions here:
http://piranhacms.org/docs/pages/regions
Regards
/Håkan
(Using Ektron version 8.6.1)
Say I have a smartform ContactInfo, something like:
<ContactInfo>
<Name></Name>
<Email></Email>
</ContactInfo>
I would like to create another smartform (e.g. NewsArticle) and "embed" ContactInfo inside
<NewsArticle>
<Title></Title>
<Summary></Summary>
...
<ContactInfo>
<Name></Name>
<Email></Email>
</ContactInfo>
</NewsArticle>
My solution thus far has been to include a Resource Selector field to add a reference to an existing smartform instance. I would prefer to make the association at the configuration level, to make the data entry workflow more intuitive.
I'm using Bill Cava's ContentTypes and generating classes from smartform XSDs, so it would also make the presentation code more natural and type-safe in that embedded fields could be accessed directly (rather than having to make another request based on a reference ID, which may or may not be an ID to the smartform I'm expecting).
I gather this is not possible out of the box; I'm not opposed to hacking Workarea code to make something like this work. Does anyone have experience with a scenario like this?
I heard from an Ektron rep that they are planning on elevating the role of smartforms in an upcoming summer release - can anyone offer some more info to that point? Perhaps smartform composition like I've described will be supported?
Currently it isn't possible to do smartform composition. Depending on why/if you actually need a second smartform definition, you could just define the contact info in the news article.
If the contact info smartforms are related to the news articles in a one to many or many to many fashion, then using the resource selector as you have is the only way that I know of to create the relationship you are looking for.
If the relationship is one-to-one or many-to-one, then I'd suggest doing away with the separate smartform definition.
If you can clarify the workflow you are trying to achieve for the content authors, I might be able to respond better.
The Content Types would represent the data in the CMS. Suppose, as in your example, a NewsArticle contains a reference to a ContactInfo. Embedding the ContactInfo inside your NewsArticle might make sense from a presentation perspective, but it turns your ContentTypes into a one-way data model. You would lose the ability to construct a new NewsArticle and persist it into the CMS.
What might work well for you is to leave the content types as-is, with the id of the ContactInfo from the resource selector. Then create a NewsArticleDisplayModel... essentially a view model that contains the news article data plus ContactName and ContactEmail.
Now, if you need the contact info to be searchable, you could get really fancy with CMS Extensions and hook into the OnBeforePublish event to update searchable metadata with the name from the ContactInfo, so that the NewsArticle can be searched for using the values from the other "embedded" resource. That could get kinda tricky, though... ideally you'd have to also hook into the publish events of the ContactInfo objects in case something changes on that side, too. Then do you create a custom database table to track which NewsArticle content ids are using a particular ContactInfo?
Your solution can get as complex as it needs to, but I would keep the content blocks separate. If nothing else, you'll end up with a more maintainable and upgradable solution.
I have two models, we'll call them Entry and Comments for our example, that are associated as Entry has_many :comments and Comment belongs_to Entry. When a new comment is created, I need to obviously supply the id of the Entry for the foreign key. Right now, I'm using a query string. It works like this. A user views and entry, clicks a link to create a new comment (the link looks something like b/new?a_id=1) and then I use the build method to create the new record.
I know if I nested the resources it'd work just fine, but there are reasons that I don't want to do that, namely that I plan to nest a resource under Comments and don't want to go so many levels deep.
I initially had the form for a new comment on the Entry show page, but was having problems doing some custom validations and passing the error messages, etc. (namely, I needed to count the words before submitting).
Any thoughts? I'm not opposed to using query strings, just not sure if there's a better way.
I honestly can't see the problem with nested resources. You're going to have to identify the Entry in your case so your choices are POST /entries/123/comments or POST /comments?entry_id=123. Personally I prefer the former.
I am creating a web site for a customer and they want to be able to create articles. My idea is to tag them so I am going to implement the system.
What is the best design, both from an architectural and a perfomance perspective:
1. To have table with all tags and then have a one to many relationship table that links a tag like this:
articles table with ID
tags table with ID
one to many table with columns Article.ID and Tags.ID
2. To have one table with articles and one with tags for articles like this:
articles table with ID
tags table with Article.ID and tag text
Thanks in advance!
Your first option is the most appropriate and theoretically right.
Guess, your clients do not think tags like a nice feature to have because everybody has it - they would like to have search by tags. Even if they don't yet understand their needs and really want to have tags because everybody around has them - they will realize their needs soon.
First option will give you better search operation performance.
Implement separate table for articles, tags and many-to-many between them.
Definitely the first option.
Apart from the other benefits, you could enforce some regularity in using tags, by checking if the tag (or a similar one) is already present before adding it, allowing users to select from existing tags, and/or allowing only superusers to add new tags.
This way you avoid mispellings or alternate spellings of the same tags (i.e. US, USA, USofA, U.S.A., U.S, US., America, Amerika, Amrica and so on when labelling something about the United States)