Displaying Form Fields on Page

Carlos Batista asked on December 15, 2015 16:35

Hey guys, I need some help to figure out how to architecture a page that is simply supposed to display information from the form fields that exist in its page type. For instance lets say I have a page type for smartphones with a bunch of fields. I make an instance of this page and call it iPhone. Now when I open the page iPhone, I create a template for it then I go to the design view and I drag in webparts to display a complex smartphone page.

My question is: Which webpart should I use to simple display this iPhone's page fields? Should I use a repeater? A static HTML webpart? The default transformation? What makes more sense to do when trying to display the page's own information that's contained within its form? What is the most flexible approach that will also make it easier to deal with complex views that pull data from multiple places while also keeping in mind things like localization and language?

Thanks in advance

webpart repeater pagetype

Recent Answers

Brenden Kehren answered on December 15, 2015 16:57

What is recommended is to use a repeater for the listing view, then set the selected transformation to the transformation you've created for the detail view.

Knowing detail pages are often quite complex, I'll typically use a repeater for areas that have a lot of detail grouped together. For other one-off areas like a page header I'll use a static text webpart and set the default value to a macro with simply the column name in as the macro value.

For instance {% ColumnName %}. This works well and doesn't end up creating a lot of additional calls to the database.

3 votesVote for this answer Mark as a Correct answer

Carlos Batista answered on December 15, 2015 17:07 (last edited on December 15, 2015 17:07)

"What is recommended is to use a repeater for the listing view, then set the selected transformation to the transformation you've created for the detail view."

The problem with this is that this page is very complex, imagine not only having to display the information from the iPhone itself but also references to staff members (other page type) who are experts on iPhones, plus most recent news about iPhones, plus a couple of CTA modules to signup to receive newsletters about Apple Products. Would the default transformation approach still satisfy this without being extremely cumbersome?

0 votesVote for this answer Mark as a Correct answer

David te Kloese answered on December 15, 2015 17:11 (last edited on December 15, 2015 17:11)

Hi Carlos,

Id use different webparts for each functionality.

related pages (staff members)
news listing
CTA links
newsletter sign up
etc

If you decided to use the same page template for both the listing and the detail view. You can use the visibility settings on each webpart to determine if it needs to display. This way you can only show your phone news on the phone detail page for instance.

Greets,

David

0 votesVote for this answer Mark as a Correct answer

Brenden Kehren answered on December 15, 2015 20:43

@Carlos,

As I mentioned, knowing your instance of the details page is pretty complex, I'd work through and group items you can in a repeater. Items which may be off on their own, use a static text web part with a macro. For any other types of related data, use a related data web part.

The goal is to display the data the way it was designed and also have the page be as quick as possible (not a lot of db queries). So if the data you're retrieving is specific to that product, then use a macro and the static text web part, if it is related somehow (custom table, like items, related pages, categories, etc.) then use another appropriate web part.

0 votesVote for this answer Mark as a Correct answer