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.
Related
I would like to customize start/end of OOTB CQ5 user form component to start with certain custom components pre-populated when the 'form' component is drag/dropped on to the page.
I currently have an over-laid /apps/foundation/components/form elements with start/end/actions customized. But I am to figure out way to add a component belonging to the FORM group, to the form start.......end to the page whenever a form is added to the page.
I have tried using a <cq:include path= "customComp" resourceType="/pathto/customComponent" /> to the jsp of the form-end component, this adds / shows the custom-component on display but does not perform the server-validations as it is not a separate node between the start and end nodes on the page, but a dynamically added one.
This is basically to enforce/mandate the use of my custom captcha component whenever a form is placed on a page.
thanks in Advance !
If you want to leave the form creation entirely to the author (as intended with OOTB components) there is no easy way to "sneak in" a mandatory captcha component. Even if you managed to put in the captcha component, the author can just delete it or move it out of your paragraph system.
Mingling the captcha with form-end might be possible, but not without reinventing the form-end component pretty much from scratch. I wouldn't want to do that.
I see three options that might be helpful to you:
Implement a jcr EventListener that will fire whenever a form is created or changed. Check the form data structure in jcr and when the mandatory captcha component is missing, add it and commit. This type of behaviour is of course a little shady and may suprise authors - but it's gonna work.
Build a wrapper form component that contains a paragraph system with a fully pre-configured form, including form-start, captcha and form-end. This approach my even save authors a bit of work and nobody will "forget" about the chaptcha easily. Nothing will stop an evil author from explicitly deleting the catpcha component however.
Build an entirely custom form component that does not utilizy any of the OOTB components. In this scenario you have full control over what the author can and cannot do. Most likely you will give up on a lot of flexibility in order to save development time and end up with a mostly static form where the author can edit a few cruicial parts.
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 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.)
I am working with Drupal and Views module.
I am using the same theme with different Views.
I have created different pages which are listing nodes per viewname as this : views-view-fields--VIEWNAME--page.tpl.php but now when I click on an article title, I would like to personalize the node with the viewname, so I would like to use node-VIEWNAME.tpl.php, but it's not possible. The only thing I can do, is to create a node-TYPE.tpl.php but I do not want to follow this way.
So my question is how can I implement (may be with a hook function?) the node-VIEWNAME.tpl.php when I click on an article title (so when I have only one full article and which is defined by it's id in the url. This is for precision, I am not fluent in English.
Thank you very much !
Alexandre
The correct way to do what you're attempting - use the Display Suite module, set the view to point to a Display Suite object in the field settings, then click the gear next to that setting and pick the build mode you want to use. Then in your template.php file, do whatever special work you need to do to that build mode.
I want to list states in a combo box to be displayed in block in left side bar.
Depending on the selecting of state I want to filter the HTML code within page nodes.
How can I do it?
If you are unfamilliar with how Drupal modules are created, work through Creating modules - a tutorial: Drupal 6.x
Create a form. The Forms API QuickStart Guide and the Forms API Reference tell you how this is done in Drupal.
Put the form into a block by implementing hook_block.
How to proceed from there depends largely on what type of filtering you need. In any case hook_nodeapi is invoked on various node-related occasions, so you might want to implement it to do the actual filtering.