I have a form built in Kentico and want to change the form action to point to a marketing automation vendor website (eloqua) to process the form. I noticed that there's no way to change the Action on the Form app, so I thought of using js to replace the action dynamically. I'm not sure whether it'll work, but another immediate problem I have is the field name/id generated by Kentico is so long (> 70 characters - e.g. p$lt$ctl02$pageplaceholder$p$lt$ctl03$On_lineForm$viewBiz$Company$txtText) and exceeds the length allowed by the vendor. Is there a way to shorten those names/ids?
To clarify, the reason I need to edit the name because the vendor allows to map (copy/paste) html name to whatever name it's using. I've tried pasting the whole string from one Kentico field and got the error message of exceeding character limit.
First part of the question, how do i direct a form to submit to another site?
In ASP.Net, the only way is to use javascript to alter the 's action url. Since you want to be careful where you edit this, i would use jQuery to replace the "Submit" button on your form with a javascript function that will alter the form before submission (so you don't mess up other postbacks)
$("button.MySubmitButton").click(function() {
$("form").attr("action", "http://TheVendor.com/PostLocation");
});
Next question is to alter the field names. If you absolutely MUST have form element IDs sub 70 characters, you will have to use Javascript again and it will break any postback-related functionality of the elements, so make sure the form is "as is" before doing it.
Again there is security concern because when you post to another location, you are sending ALL the data, including hidden asp.net inputs that contain viewstates and the like. You may want to take the time to 'eliminate' right before you submit any field that you don't want sent to the other site.
Something like this (Test it out a bit first though)
$("input:not(id*='txtName'):not(id*='txtEmail'),select:not(id*='ddlQuestion')").remove();
As #trevor-j-fayas points out, you can use javascript to point a form action to another url. While this does work you may end up writing a lot of javascript to not only point the form to a new url but also to do some data massaging (changing id's, doing url formatting, etc) before sending it to the target.
Additionally you lose some of the benefits of using a Kentico Form because the data never actually gets submitted back to Kentico such as email alerts.
I have worked in a similar scenario where were we sending data to Eloqua but instead of doing it client side we did it from the server by using either:
The OnOnAfterSave event on the BizForm control itself
The global BizForm submit hook BizFormInfo.TYPEINFO.Events.Insert.After
After the form is submitted to Kentico, our custom hook code runs which sends the data to Eloqua. In either hook you can fully access the Form metadata, field names, and submitted values. You can then craft an HTTP POST request and submit it asynchronously using a class such as HttpClient.
Is not a good idea from the architecture stand point and most likely not going to work without opening a huge hole in their vendor web site security. First of all how are they going to process the from if they don't know the field names, what if form fields change etc. Secondly you going to run into hell of trouble trying to submit form one site to another etc. What if the vendor site is not responding etc.
What you need to do is submit the form back to kentico web site i.e. process it on kentico web site and send email notification with results to marketing automation vendor website (the easy way for now) and redirect user to vendor web site.
Redirection and email - you can do out of the box without any programming. Actually to do all the above requires no programming and you get all the information recorded on your Kentico site.
Related
In our old project we're using Alfresco 4.2.c community version.
There's a task page there, were you can use predefined filters to manage data you want to see.
I was able to add some extra filters there, anyway another problem stands in my way.
There's a paginator there, probably from YUI, which works by two parameters, maxCount and skipCount.
Right now it's configured to show max 400 records on one page.
I'm trying to add an option to display all records at once. Is anyone familiar enough with that system to even tell if it's possible? YUI framework is very hard to manage.
It seems like on every page or filter change it redirects you to ahref='#', a then a method reads the filter id and gives some extra parameters to the request. I can't find a way to maybe bind another button to reload the page in the same manner and just add another line to the request, which would make the paginator show all the records at one page.
I've got a form that gets filled out in stages so I wanted to direct users to a secondary edit form part way through the process. Is this possible?
Hide and reveal using JQuery on the editform.aspx would be my initial choice. I've done this type of work for a very well known bank and it worked very well. Single form with different sections of the form to fill in dependant on the answers provided (and the user group membership)
If you actually want to maintain two lists and hence two forms and redirect between the two - I would look into changing the "source" querystring parameter in the editform so that on completion of the form, you get directed to an alternate location. Not tried it but it would be a sensible place to start looking.
I'm making a custom search box Web Part, similar to the OOTB Web Part from SharePoint
(SearchBoxEx class).
I'm interested in modifying the search query with additional text before it is submitted, based on a custom checkbox added on the Web Part.
Any help on how I can achieve this?
UPDATE:
I've used the AppendToQuery and AppQueryTerms properties, but this will rewrite the text in the search box as well. I'm interested in passing the values "in the background", maybe as an extra parameter. Point is that the query modification should happen without the user seeing it explicitly.
In the core result webpart there is a property where you can append text to the query and you will not see that in the textbox.
Best,
Bibhu
I when I had to customize People Search, I opted to roll my own web part and just called Response.Transfer to the Results.aspx and appended query string parameters to the URL. This wasn't the most elegant solution, but it was a quick way to modify the query "behind the scenes."
I'm sure you could develop an application page and set it as the Search Box web part's Results page. Put your custom logic in the page_load and then transfer (or do a form POST) to the actual results.aspx page.
I'm now developing an Extension of SearchBoxEx myself, and I'm currently trying to figure out how to call the base method that submits the query too. This blog shows how to call the internal CreateAdvanceSearchLink method of the SearchBoxEx class: http://pholpar.wordpress.com/category/search/
I am trying to split out what I originally wanted in a single form. The downside was that I wanted to keep multiple lists and I found that I could not use a single form with multiple lists.
What I am trying to do is to keep my customer information in a separate list/form so I can re-use it in a different application as well.
What I would like to do is give a picker to pick the customer from a list, and if the customer is not listed to allow the creation of a new one.
What I am wondering is how I can leave the main form, create the new customer, and then return to the main form but with the new customer information passed to the new form as selected. In ASP.NET one of the ways I would do this is through the querystring, but I am not sure if that is doable or preferred in Sharepoint.
Any thoughts or links to tutorials would be great.
Please keep in mind that due to access/security limitations I am trying to do this strictly through the browser and Sharepoint Designer.
Thanks!
With your access limitations, I don't see a solution that will allow the refresh of the original form to get the new data. You may be able to hack in some JQuery stuff to do this, but I just don't see it being an easy/value-for-time thing to do.
You may just have to allow the form user to save the form without customer info and come back to it.
A list view can then highlight forms with no customer info. This all depends on the usage scenario.
You can use the Source query string parameter to get you back to the original form after completing the new customer form. However, unless you add some code (either javascript or server side) you won't get the id of the new customer.
The best option is probably using jquery and the sharepoint web services. It's quite easy if you start with the right scripts, and you can do something like your original plan - make a simple form in a jquery ui popup.
You can also use javascript to manage linking between multiple forms, but you need to be careful about clearing out already entered form data.
Another option would be to edit dispform.aspx and add dataviews for other lists, along with appropriate add buttons, and add javascript to the new customer form that sets the value of a connecting lookup field. However, that tends to require quite a bit of messing about with list guids and other undocumented bits.
I have a custom SharePoint application page deployed to the _layouts folder. It's a custom "new form" for a custom content type. During my interactions with this page, I will need to add an item to my list. When the page first loads, I can use SPContext.Current.List to see the current list I'm working with. But after I fill in my form and the form posts back onto itself and IsPostBack is true, then SPContext.Current.List is null so I can't find the list that I need to add my stuff into.
Is this expected?
How should I retain some info about my context list across the postback? Should I just populate some asp:hidden control with my list's guid and then just pull it back from that on the postback? That seems safe, I guess.
FWIW, this is the MOSS 2007 Standard version.
Generally speaking I try and copy whatever approach the product group has taken when looking to add functionality of my own. In this case they add their own edit/view/add pages via the list definition itself.
I built a solution that also needed its own custom "New" form, not open source unfortunately, though if you are interested you can download it, its called "Tagged Links" (Social Bookmarking for SharePoint) and you can find some links on my blog.
To give you a few hints and tips, the following should set you off in the right direction:
Created a new list definition.
Created a new Content Type In the content type you can define your own "FormTemplates" that references a Rendering Template which determine what gets displayed in the "Middle" bit of those forms.
Copied the standard Rendering Template, but then made the changes to it that I
needed.
Wrapped it all up in a solution, and deployed.
My Rendering Template actually included an overridden "Save" Button where I did a lot of the extra work I needed to do during the save.
Anyway, it is a little too much work in my opinion but, I think, it most closely matches the standard approach taken by the product developers. Let me know if you need more detail and I will see if I can put together a step-by-step blog post, but hopefully this gets you off on the right direction.
I would be surprised if you could do something in a _Layouts file that you can't do in a forms template. You have pretty much the same technologies at your disposal.
Looking at the way SharePoint works with ListItems and Layouts pages (for example "Manage Permissions" on a list item), I can see that they pass some variables in via querystrings:
?obj={76113B3A-FABA-4389-BC85-4BB2CC5AB423},6,LISTITEM&List={76113B3A-FABA-4389-BC85-4BB2CC5AB423}
Perhaps they grab the context back each time programmatically using these values.
I'm not using a custom "new form", so this might not apply. I added an event receiver to my custom content type and then do my custom code in the ItemAdded or ItemAdding events. This code fires when the event is added to a list. You can use the event receiver properties to get to the parent List, Web, and Site.
I'd like to think my issue is "special" here, since I am using a custom form. I chose to use a custom form rather than a custom FormTemplate simply because I'm doing a lot of stuff that's not very SharePoint list-like (making ajax calls to get info from a third-party app then generating some dynamic form elements based on that ajax result, then subsequent processing of that data on postback). I thought it'd be a nightmare to try this within the usual custom rendering template mechanism.
I also don't think I can supply the custom form declarations in the list definition itself, because I have multiple content types associated with this list, and each content type has its own custom form (the other type is thankfully much simpler).
Actually, my simple way of keeping the list guid in my hidden field was a very low impact way to address this specific problem. My main concern is that I'm not sure why the SPContext just loses all its usefulness when I postback here, which makes me think I'm doing something wrong.