I have a checkout page on my site which lists items that customer is purchasing... and below the basic list is a "Detailed Invoice" section where they can see specific info on each. Up 'til now I only had two different types of items that could be purchased, so the detailed listing was fairly easy to handle. Now I'm adding four additional and completely different things that are purchasable... so the question: What is a good way of handling this sort of rendering using Sitecore sublayouts? (Currently, I just use a Repeater and hide/show appropriate fields)
The good news is, for each line item in an order there is an associated Sitecore Item instance. If the Sitecore API was better suited to object-oriented methodology, I might create a Render() method on each of my object types in question. But of course they are each Sitecore.Data.Items.Item objects. Subclass Item? This seems like overkill for just this task...
Something I've considered is a Sublayout/user control for each different item type... and then dynamically add them to a Placeholder on the invoice page. This seems reasonable... Thoughts? The downside is then the ugly code that has to match up the user control with the item... based on TemplateID maybe?
Anyway, just looking for some suggestions here.
Building classes to represent Sitecore data is not an unreasonable idea. This is a perfect scenario to to do it. Whenever I build project I always have classes generated using the Custom Item Generator in case I need template-specific field access. I also do everything as sublayouts so I can see your dilemma.
Are all/most of the fields unique to each product? You don't have a generic product template that each product instance uses?
These are the options I can think of myself (worst to best IMO):
Create a class to represent each unique template. The Custom Item Generator may work, but it may confuse you the first time. You can always make your own classes where you pass the Sitecore item into the constructor and create properties to access fields. Then use regular .NET controls and bind data to the front-end based on which template your item uses and using the strongly-type class for the template. This will likely be messy code of many if-else's.
Create a unique sublayout for each unique template in Sitecore. In your repeater that loops over the items, based on which template the item is, add the right sublayout to the placeholder using new Sublayout() and set the DataSource as the Sitecore item (here's code to access the DataSource). That way you abstract the implementation to each unique template.
Create classes for each template as mentioned in #1, but abstract across them all with an interface. In your repeater's ItemDataBound, implement data via the interface. This highly depends on how the fields compare and contrast from template to template. If you can force yourself to reduce the unique fields into the interface's members then each class that represents a template can just implement your interface. This allows for the future addition of more unique templates, as long as you continue to implement the interface.
This to me seems like a good place to use the "Presentation Inversion of Control" Sitecore pattern (as named by Aware Web).
http://www.awareweb.com/AwareBlog/Presentation%20Inversion%20of%20Control%20part%202.aspx
Though the blog post discusses this more in a context of user-placed items, it works here too. If you have a template for each product type, you could define presentation details on each (perhaps in a separate Device) that define the control which can render that item in the cart. Then you can read the RenderingReference's off the item, and place them into the page. This makes for a flexible, extensible system that allows you to handle different output for different types of products.
This is close to the solution you describe (Sublayout for each product type), but allows the sublayout to be data driven instead of conditional logic for each TemplateID. (Note you will need to assign a dummy "main layout" in the presentation details as well.)
Related
I am starting to build an app, using Meteor, that includes user-populated company profiles (including both financial data and text). I will be looking into a datafeed for public company information but much of the information for private companies will be user-populated.
I know I will need to create a form for the user to fill in so that the company information will be captured by the database. However, can I make this same form available to the user to both display the data and to allow them to edit the data in the future? Or do I need to build a separate view using tables for this purpose? My preference is the former, just one screen to create and edit as needed.
Any examples of similar instances would be very appreciated.
Thank you.
This is less of a meteor specific question, rather a general web technology question. Meteor can provide the data in the template of course, and it can offer events to process data and insert/update this to a database. This is the same as any underlying architecture. The question is really how to approach the problem with HTML & JavaScript.
A couple of potential methods:
Write your HTML to display the content in its non-editable form. Then provide an edit button to switch mode. When clicking this button switch on 'contenteditable' for the elements you wish to be edited: http://html5doctor.com/the-contenteditable-attribute/
Also reveal a save button, then process the event through meteor. Use selectors to extract the fields by referencing either designated class names, data attributes or name attributes. It would also be a good idea to alter the appearance of editable elements with a background or outline. The disadvantage here is that it's slightly non-standard and you may have the need for more complex data-types like dropdowns or checkboxes etc.
Create view with a standard form HTML. Style it in a way that shapes the information primarily for display rather than editing, eg. hide form field borders. Provide an edit button that when clicked alters the CSS and reveals form field borders, also reveal/replace elements which need more complex controls like dropdowns, perhaps turn on field labels too and of course a save button. The disadvantage is slightly more complex CSS and JavaScript.
Is it possible to create an extender of a content type (just adding a couple new fields) that is also accepted by any custom content types using the original type's schema?
I am working on an idea I had for a new feature on PloneFormGen. I originally was going to fork and modify the core product, but figured it would be more acceptable to create a separate add-on that extends PFG. So, I started creating my extender.py and all the necessary bits with it to extend PloneFormGen Form Folder.
However, our company has a custom content type that is an extension of the form folder. That got me thinking instead of just accounting for the standard Form Folder, could I either account for all types using form folder as a base, or provide a control panel where the site admins can specify the types for the extender to apply to?
Or, is there a better way to create our custom types so it not only grabs the core schema, but any extenders for it as well?
To explain in more detail what I am adding, it is not a field, or an action adapter. Basically, it is a new feature called Skip Logic. It provides the ability to hide/display fields based on values of other fields live using jQuery. As opposed to creating custom JS overrides for each form, this allows a content editor, or whoever builds the forms, to control this functionality with no code. There is a JS file that is loaded, and it uses a JSON string to determine the hide/show functionality. I created a form template that can be used to manage this which pulls in all available form fields to choose from.
My idea for implementation was to add two new catalog indexes to the PFG form. One is a boolean which toggles skip logic enabled/disabled. The other is a string which holds the JSON string, which is created by using the form UI (think like a new tab similar to QuickEdit).
If anyone has a better solution for how to implement, I am all ears. Either modifying the core product, or extending it were the only two I could think of.
SchemaExtenders adapt an interface and not the class itself, so for your simple "extending FormFolder" example, you shouldn't need to do anything special. You can even adapt to a marker interface that doesn't do anything useful by itself and make classes implement that interface "externally" (just excerpts from local code here):
class IIllustratableContent(Interface):
"""This content has an image reference it sometimes might use"""
class IllustratableExtender(object):
adapts(IIllustratableContent)
implements(
ISchemaExtender,
IBrowserLayerAwareExtender,
)
# do stuff
and configure.zcml:
<adapter
name="illustratedContent"
factory=".illustratedContent.IllustratableExtender"
provides="archetypes.schemaextender.interfaces.ISchemaExtender"
/>
<five:implements
class="Products.ATContentTypes.content.document.ATDocument"
interface=".illustratedContent.IIllustratableContent"
/> <!-- and for some other classes, too -->
I want to control some fields in a dynamic data edit page.
So for example :
when a specific type is chosen in a combobox, other input fields should be disabled or should be set to a specific value.
How should this logic be implemented, a custom edit page ?
Or can it be controlled from the model metadata ?
Usually the best path in Dynamic Data it's to act on the metadata side; the basic enviroment don't implement every requirement you've listed but it's relatively easy to add those functions if you check the work done here:
http://csharpbits.notaclue.net/
The main point of the DD it's the templating system: going the custom page route too easily/often, in my opinion, defy that point.
F.
I'm looking for the way for the site's administrator / moderator to find / filter the list of nodes by some field custom value. Field value could be defined by radio / text / checkbox etc.
Default content listing proposes only few filters, it's not enough for sites with huge amount of custom nodes.
Use an EntityFieldQuery object, documented here:
http://api.drupal.org/api/drupal/includes--entity.inc/class/EntityFieldQuery/7
The documentation has no examples (ugh), but there's a thread here with some:
http://drupal.org/node/916776
EDIT: Ah, you're talking about administration and not actually writing a module to do it. If that's the case, use a view with exposed filters, like the other guy said. :)
Maybe it would help to use a view for it, where you set filters, so that you get the desired listing.
I had to test this, but I've just confirmed. Views in Drupal 7 can indeed filter across multiple content types w/ custom fields, and still have filters apply to those custom fields. They seem to treat the nodes w/o those custom fields as empty or null values.
So for instance, I have article and blog content types. Blog has images, article does not. I can sort or filter on the image field, even though article doesn't have it. It simply assumes the field is null or empty.
This however, may not solve your problem of having a large number of custom fields. If these are dynamic (i.e. they grow over time) you might be in trouble. If, however, they are set, and just a very large number, you could manage this.
So while there is no automatic add all fields, which I believe you mentioned in a previous post, you could feasibly search on a large variety of the fields. Even exposing fields that you don't necessarily display in the table, but can then search on. Or changing the fields you expose or display on a per page basis in the view. All from one view. And then you could export the view to bring it over to the other sites.
I was going to try and attach the exported view, but the export is rather large for inclusion in an answer, I think. Please let me know if you think I should still include it, or if you'd rather I can simply send it to you through a PM. Let me know!
EDIT: I decided to include a link to an export of the view. http://greggalante.com/sites/greggalante.com/files/cross_type_view.txt
http://drupal.org/project/search_api
It may sound 'weird' but I need to have a view that lists all the content types I have.
For example i have two content types : contenttypeA, contenttypeB
I want to create a view that just displays the two content types (and show number of items of that type, but that can be done later).
For now what I did is add one content of each content type and list them but only show the 'node type'; it works well if there's at least one content but I want to display even without any content of that content type.
Any idea ?
Introducing the node_type table to Views requires a custom module and some Views API knowledge however http://drupal.org/node/1001222 will give you a head start.
Use a Customfield: PHP code field and custom code the whole thing with PHP. This is provided by the Views Custom Field module.
Use the Table Wizard module to make the node_type table available to views. You may need to use the Data module as well since they say that all future development is going there.
Expose the node_type table yourself by writing a custom module using the Views API as suggested by chx.
Number one is the quick and dirty way, but number 2 might be a little more manageable, but I am not completely sure it will do everything you want. If you do number 3 make sure you contribute back to the community by putting your module on drupal.org.
There is no native functionality in Views to do that. You can write a static page or (overkill) a module that provide a "system"-like type similar to Views Watchdog.