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.
Related
I'm building a CRUD for users in my rest API, and currently my GET route looks like this:
get("/api/users/:id")
But this just occured to me: what if a users tries to search for other users via their username?
So I thought about implementing another route, like so:
get("api/users/username/:id")
But this just looks a bit reduntant to me. Even more so if ever my app should allow searching for actual names as well. Would I then need 3 routes?
So in this wonderful community, are there any experienced web developers that could tell me how they would handle having to search for a user via their username?
Obs: if you need more details, just comment about it and I'll promptly update my question 🙃
how they would handle having to search for a user via their username?
How would you support this on a web site?
You would probably have a form; that form would have an input control that would allow the user to provide a user name. When the user submit the form, the browser would copy the form input controls into an application/x-www-form-urlencoded document (as described by the HTTP standard), then substitute that document as the query_part of the form action, and submit the query.
So the resulting request would perhaps look like
GET /api/users?username=GuiMendel HTTP/x.y
You could, of course, have as many different forms as you like, with different combinations of input controls. Some of those forms might share actions, but not necessarily.
so I could just have my controller for GET "/api/users" redirect to an action based on the inputs?
REST doesn't care about "controllers" -- that's an implementation detail; the whole point is that the client doesn't need to know how the server produces a representation of the resource, we just need to know how to ask for it (via the "uniform interface").
Your routing framework might care a great deal, but again that's just another implementation detail hiding behind the facade.
for example, there were no inputs, it would return all users (index), but with the input you suggested, it would filter out only users whose usernames matched the input? Did I get it right?
Yup, that's fine.
From the point of view of a REST client
/api/users
/api/users?username=GuiMendel
These identify different resources; the two resources don't have to have any meaningful relationship with each other at all. The machines don't care (human beings do care, so we normally design our identifiers in such a way that at least some human beings have an easy time of it -- for example, we might optimize our identifiers to make things easy when operators are reading the access logs).
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?
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 need to create a form on my page which would accept values from the end user, validate the input (basic stuff, nothing fancy, to check whether required fields are filled etc.) along with a captcha to eliminate spam bots.
Currently, I have a standalone reCaptcha component set up for my form. It works fine on it's own. I was thinking along the lines of adding this along with any of the out of the box form components that CQ5 provides (the address component caught my fancy).
The problem arises with the validation. When I click submit, the validations for the address component never seem to execute. Which leads me to my question.
i) Is it allowed for me to continue with my current methodology (i.e 1 main form component which contains one reCaptcha component and one address component)? If I can, how can I map the validations accurately for the entire form to behave as I want when I hit submit. (I would need the address form to check for required fields, the reCaptcha to check if the challenge field is valid, in that order)
ii) If I cannot carry out the task in this way, would I have to create an entirely new component for my form, one which includes the code for both the address component and the reCaptcha component and include both their validations within 1 file? Logically, I can see the merit of this approach, it does seem much easier. But I would like to maintain the reCaptcha component as a stand alone, to effect reusability across my site.
A similar topic does exist on how to handle Multiple forms on a single page, but since it involves Ruby, which I have next to zero knowledge on, I couldn't really implement.
I'd appreciate it if I could get some information on how to achieve this in context to CQ5.
Thanks
(apologies for the really long wall of text)
after tinkering about with my form for a while, I was eventually able to get it to work!
So, yes it is indeed possible to have a multiple form components within a single form. The issue with validations can be sorted out by taking a look at how the validations are managed for any of the OOTB form field components individually.
To clarify, the OOTB Captcha component uses the Layout.printError() method to display any issues with validation. I sorta reworked this into my Recaptcha component, and made the necessary changes into the servervalidation.jsp. Worked fine!
And with respect to the 2nd point in the question, I'd suggest not going down that road as I feel it's always better if my component is stand alone.
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