I'm developing a custom module that has to send some information to a Web Service after a Product is inserted, updated or deleted.
In order to ensure that all the fields required by the Web Service exist, I have decided that the module should be the one in charge to put them in the Product form. I achieved It by extending the commerce_product_product_form function.
But now, I have noticed that the values for the fields that I have added are not saved, so I supposed that I have to define a custom table in the module to store the additional information.
I have taken the example from AutoSKU regarding how to save and load data for Product Types form. But, what I've not found is how to do, or what are the hooks for saving and loading data for the Product form.
So, my questions are:
Is It correct what I'm thinking about creating a new table for storing the additional information that I require or can It be implemented as part of the existent routines that the commerce module handles?
If the module has to save and load the data by using a custom table, What are the hooks that I should use in order to append the form data and save It to the module tables?
If I can store the information using the commerce routines, What should be the way and/or the hooks to define the custom form fieds?
Can you tell me if there is any example about how to achieve this?, I have seen some modules but, basically all of them just modified a behavior of the existent fields, they don't add new fields, as far as I could see. The modules that I have reviewed are:
commerce_custom_product
commerce_dressing_room
commerce_fancy_attributes
commerce_tickets
I would like to achieve this by using the commerce and Drupal best practices but I need to finish this module as soon as possible. So, in the meanwhile I'll be saving the data to a custom table and loading the additional information in the commerce_product_product_form hook and saving the information in the commerce_product_save hook.
For loading the data I have tried with the hook_commerce_product_load and hook_entity_load, but for some reason the call seems never happening (I'm sending some information to Watch Dog but It's never displayed), I also have tried by clearing the cache without any change.
Any help would be appreciate.
Thanks in advanced
Are these fields going to be created during normal use of the application (hourly/daily)? Or are they only being added at the beginning (initialization process)?
If the latter, you could create an install script similar to the ones found with many, many modules out there (module-name.install).
Have you considered adding the fields to the content type?
Related
I have an issue where forms are validated and if do not pass validation (validation is done in the back-end) are re displayed with original submitted data for the user to change. Originally this was not huge as I could just pass param data back into the template and have it re-displayed to the user. However, I came across issues with getting drop-downs and check boxes to retain the submitters original choices.
I checked out some of the Dancer friendly modules that did form validation and they seem nice, however, I have one more constraint: The forms and data selected needs to be able to be rebuilt and displayed again at a later time. So that means the data will need to be retrieved and the form built again displaying the same information previously selected, dropdowns already preselected, checkboxes checked, and data with the inputs.
I do not mind generating the forms and their selections dynamically from the backend using CGI form generating methods, but how can I get that data to play nice with dancer and display inside of a template?
If you're going to redisplay at a later time, it seems to me that you could go with a poor man's solution--save the rendered form with stuff selected to disk or database, and when it needs to be displayed again, just thow that cached stuff at them--or write the params to storage, and when you need to redisplay, go through the same code that generates the form now but use the saved params.
The "poor man's method" would be easy to implement but would bite you later when you find you are showing people stale versions of the form or whatever. (This is also a possible issue with the other version--the set of parameters might change over time, so there's risk there, too, but I would think less risk as you are caching less.)
I'm sorry that this is a "how to solve your problem" answer rather than a "here's a module that solves your problem answer". However, it's not too hard to store a set of params as a json blob or some other sort of frozen object, and there are modules for all the pieces of this.
I am new to Zend and still learning.
I need to read some configuration data from the database and keep it in session. I want this data in all the pages, so I need to intercept all the request and check if the session contains the required data, if not I will fetch it from the database and put it in the session.
I would like to know the best place to put the code in. In Java we used to check that in a filter. I am guessing here I have to put this is in an Action Helper. Just wanted to check what options I have and what are the best practices.
Thanks for any suggestions.
for that purposes you may use Zend_Registry singleton class for providing accessibility of session data from every point of ZF-project. For storing session data there are also several classes, e.g. Zend_Session class
I would definitely put this in a Controller Plugin class. eg.
Application_Controllerplugins_SessConfig extends Zend_Controller_Plugin_Abstract
This way you can catch the request early on, and do whatever you want with the data...
This is another answer of mine on SSL routing, but the logic is the same for the plugin class: How to implement SSL in Zend MVC
i am about to implement a similar solution whereby an application instance (which is to be rolled out to various customers) needs certain settings-data to be editable by admin via cms and thus am storing it in the db. i am then going to retrieve and add these settings [as a sub-object] to the config class (which in turn is added to the registry in the bootstrap. this seems like the cleanest solution to me as then all config data are stored in the one place, regardless of their source being an ini file or the db.
i'd be interested to hear other opinions on how this is done.
rob ganly
I keep on finding myself wanting to add fields to CRM forms that don't actually represent physical fields on the entity. I want these fields to be sent in the Update message, for the benefit of my Plugins...
For example, imagine something like the out-of-the-box contact/address functionality. The main contact address is exposed as a set of fields on the Contact form. However, in actual fact there is some magic going on behind the scenes that causes an Address record to be created for the Contact containing the address details. I don't actually want to reproduce this, but it's a fair example...
Now, I know how to write a plugin that takes the address fields entered in the Create/Update message, and actually writes them into an Address object instead. That is simple enough. It seems the hard part is convincing CRM to display fields on the form for the user to enter the address data.
The only way I can see to do this is to create "fake" fields in the Contact-equivilent form, so that the form editor allows me to add the fields to the dialog. Then I have to filter these attributes out in a plugin, so the fake fields don't actually get written to the DB.
This would work, but involves filling the DB schema with fake columns that will (or should) never have any data in them. This makes future cusomisation of the system more confusing, as there are decoy fields called "DON'T USE - Address1" knocking around in all the GUIs. The problem gets worse when I need a fake Lookup field - this involves creating a fake relationship.
So: Is there a way to achieve the same thing without dumping fake garbage in the database schema?
Is there, perhaps, some way to create a form field for an arbitary attribute in Javascript on the form, such that the Attributes will be included in an Update message?
Sure, I realise I could IFrame or Silverlight something up to cater for this, but I'd rather use the genuine CRM form fields, and handle the data in the Update/Create message plugin hook.
Unfortunately, you have already mentioned the two options that I can think of: fake fields or custom IFrames.
I know it feels "dirty" but I actually haven't had much trouble doing the fake fields thing. Standardized naming conventions are your friend. I prefer fake fields over IFrames because users can still query and filter them in Advanced Find, reports, views, etc.
Just make sure they are readonly and make sure your plugins don't swallow exceptions - you want exceptions to bubble up and cancel the transaction instead of the possibility of the main record getting updated without the children.
I'm developing a site in Symfony, and I'm not sure what the best way is to handle this scenario.
I'm creating a party bookings system. Anyone can go to my frontend app and submit a new booking. Once they're finished, they'll just get a confirmation screen, they can't edit it. Easy.
Only certain users will be able to get to the admin app (it might be secured simply by being on an intranet, but that's not important, just assume it will be only accessible by admin users). They'll be able to view the list of submitted bookings. Easy.
My problem is around code re-use when allowing admin users to edit existing bookings. When you do generate-module in Symfony, the generated module (which as a newbie I'm assuming is a good example of structuring things) creates the form as a partial. I've had to customize this form a lot for my usage (lots of Javascript, etc), so of course I want to re-use this code, to be able to load an existing booking into this form. But there doesn't seem to be a way to share this partial between the apps (I've seen people mention making a plugin...but this seems complicated for this use).
I considered using an IFrame to load the form from the frontend and just passing an "id" parameter to load it in edit mode, but this would mean that the edit mode is not secure - anyone could go to the form on the frontend and pass this parameter to edit a booking.
I also considered putting all of the form display code (HTML, Javascript, etc) in a method on the form object, but this doesn't seem very MVC - all of the display code is then in the form. But this is only because I'm thinking of the form in the same way as a model - is that right?
I feel like this should be a common situation. You can share models and forms between apps, why can't you share this common form display code too?
Thanks!
You should reconsider having 2 applications in the first place. Not only you run into the code reuse problem, but also i18n, testings and other issues. I find it much easier to have 1 application with different bunch of modules for frontend and backend users. You can configure security per module. You can have one sign in form for all users and redirect them to appropriate module based on their credentials.
You can reuse partials between modules inside the same application, but you seem to be talking about two different applications (frontend and backend) so as far as i know the only way is to copy & paste the partial from one application to the other...
I have Lotus Notes application, deployed only as modifications (new forms, views, and adding a button to one of the "standard" views) in the main mail template (R7).
All these "new" forms and views are inherited in turn from my main application template.
Now, for one of these forms to function properly, it have to have a field, which is different from customer (not end user, but organization) to customer.
I do not want to break the inheritance from our template, so we can update the application easily by just sending a new template. So, I can't ask the client admin just to break the inheritance for this particular form, as it will stop all updates (or they have to be done manually).
So, let's say I have MainAppForm, which has a calculated field ClientCustomData. I'd like to have another form, which only has only one "default" field ClientCustomData. I can break the inheritance for this second form, as it has no really design elements which may change, and then the client can modify this default value to whatever they need w/o fearing that it'll be overwritten.
The question is - how from MainAppForm I can read the value from the other form?
Or - is there a way to store 2 data elements only in a mail template (I dunno, shared file, or something), so it becomes available to each user, and MainAppForm can get them, w/o a need to remove the inheritance dependency of MainAppForm from our template.
I can envision even a class library with just to functions to return this (I don't know why this approach smells to me).
Any best practices or advices?
I'm not sure if I have understood your querstion correctly, but it sounds like you want to have a small part of a larger form configurable per client. If this is the case, I think computed subforms could do the trick.
Consider the following scenario: Your application ships with the subform ClientCustomData that contains just sensible defaults for the client settings. The form MainAppForm includes this as a computed subform. It is then possible for the local admin to disable inheritance on the subform and changing the custom data without affecting inheritance on MainAppForm.
The obvious drawback is that you cannot update the ClientCustomData subform automatically once inheritance is disabled; Keep this subform as small as possible. If you find that you need more client-custom values, you can always add another subform in the same manner.
First a clarification: In Lotus Notes, you don't have forms reading from other forms. Forms are just UI objects. However, you do have back-end and front-end documents that get created with the help of Forms.
When you create a new document based on a form (for instance, a new email), you are creating a front-end document that hasn't been saved yet. That document can access other parts of itself or it can access any back-end document that has been saved.
If I'm following you correctly, you need some bit of data that is different per client/customer to be brought into documents based on MainAppForm. There are a few ways to do that. My suggestion is to use Database Profiles, which are special documents that can easily be accessed from anywhere in your database via Notes Formula language or LotusScript. Granted, you can't push data within those documents out via a template, but if you use a database profile to store your database settings your client admin can set options once and they won't get altered when the template changes.
Have a look at the #SetProfileField and #GetProfileField functions.
To answer my own question (still I do not know if I'm right in terms of Notes way of thinking, but looks promising):
I found the "Shared fields". So, I create 2 such a fields with a computed values (the ones I want to pass on), and make my MainAppForm use them. Upon installation, the admin will change the values and mark them to not refresh with the template.
I'd respect any pros and cons, provided from a Notes expert.
Thanks