I'm building a website with very small amounts of Javascript, just to add things to the page (like a contact form) without having to go to a new page.
I understand that I should build the contact page anyways (just in case the user doesn't have javascript turned on) and then use javascript if they've got it.
So where do I store the HTML for the form if I don't want to have it in two places?
(Normally I'm not so picky, but I'm curious on this one.)
If you have access to a server-side language, you can keep a separate snippet of the form in an external page. Then, you can include the snippet into the HTML content page with an appropriate include call. This has the added benefit that, for your JavaScript, you can pull the contact form from this snippet file using AJAX. In fact, many plugins allow you to display DHTML windows with HTML content. For example, check out ThickBox.
Without a server-side language, you can do something similar with frames. Just display the form snippet in a frame when you need to reference it. Personally, I don't like frames very much, so this isn't a very attractive solution for me, but you can use it if you choose (and style the frames appropriately).
Just put your HTML for the contact form in a .html file. Assuming you're using PHP or something, just include the file in your contact page and include it in the section for your dynamic contact form. The form should still submit to the same server-side page and have the same look and feel..
e.g. contactForm.html
<div class="contact-form">
<input ....>
</div>
Related
I was hoping someone had any insight on this basic approach. Sample scenario:
I have a dashboard template with menu links a(href "/page") and I want to click the links to render a different section/view on the template. I used block content...but does it need a specific route?
If I understand correctly, you want to update the content of the page on click of the link without the page getting refreshed.
In that case, no you can't do it using block content.
The purpose of block content is to apply inheritance in your templates.
The typical use of block content would be creating a layout and then creating more specific page from the layout. This is what the official documentation says.
The reason why you cannot do it because, jade is server side templating library. This resolves the block content on server. Once rendered in client, the html looses all the information that was specific to jade (which is obvious because its an html afterall).
What you can do here is
Create a /page.jade and make a ajax call to a service. That service should return an already compiled html string. Since you are using jade, you can easily use jade.compile(source, options) to template / generate html.
Jade API documentation here
Situation: I needed to add form with POST method to CMS page. I created custom hook and a module displaying the form successfully. Then I need to react to user input errors eg. when user doesn't enter email address I need to detect it, display the whole page again together with the form and with "errors" in user input clearly stated.
Problem: The problem is to display the WHOLE page again with connected information (eg. about errors etc.). In the module PHP file when I add this kind of code,
return $this->display(__FILE__, 'modulename.tpl');
it (naturally) displays ONLY the form, not the whole CMS page with the form.
In case of this code,
Tools::redirectLink('cms.php?id_cms=7');
I can't get to transfer any information by GET neither POST method.
$_POST['test'] = 1;
Tools::redirectLink('cms.php?id_cms=7&test');
I tried to assign to smarty variables too
$smarty->assign('test', '1');
(I need to use it in .tpl file where the form itself is created) but no way to get it work.
{if isset($test)}...,
{if isset($smarty.post.test)}...,
{if isset($_POST['test'])}... {* neither of these conditionals end up as true *}
Even assigning a GET parameter to url has no impact, because there is link rewriting to some kind of friendly url I guess, no matter I included other argument or not. ([SHOPNAME]/cms.php?id_cms=7&test -> [SHOPNAME]/content/7-cmspage-name)
My question is: is there a way to "redirect" or "reload" current page (or possibly any page generally) in prestashop together with my own data included?
I kind of explained the whole case so I'm open to hear a better overall solution than my (maybe I'm thinking about the case in a wrong way at all). This would be other possible answer.
The simplest method would be to use javascript to validate the form - you can use jQuery to highlight the fields that are in error; providing visual feedback on how the submission failed. In effect you don't allow the user to submit the form (and thus leave the page) until you're happy that the action will succeed. I assume that you will then redirect to another page once a successful submission has been received.
There's lots of articles and how-tos available for using javascript, and indeed jQuery for form validation. If you want to keep the site lean and mean, then you can provide an override for the CMS controller and only enqueue the script for the specific page(s) you want to use form validation on.
If the validation is complex, then you might be best using AJAX and just reloading the form section of your page via a call to your module. Hooks aren't great for this kind of thing, so you might want to consider using an alternative mnethod to inject your code onto the cms page. I've written a few articles on this alternative approach which can be found on my prestashop blog
the site that I'm working at is designed in a such way that CSS class is set for the tag on all the pages and the css classes used are different for all pages. Each page has common elements such as a header, a footer and a nav bar. I'd like to set up a single page template and include all common elements there but the body tag stands in the way. Is there a way to control a template from a content page? I know I can specify a code behind for content pages but i can't rely on content authors to enter it correctly each time they add a page. My current thinking is to set up multiple page template, one for each css class that is referenced in the body tag and put the common page elements into user controls. This is less than ideal because I will end up with lots of mostly identical templates and my user controls would not be editable easily. I guess I would have to use shared content items and such making the content authors hunt all over the site. I would have been much simpler to update the common header in a single page template.
Can someone please suggest a way?
I submitted a reply in the Sitefinity forums where you originally posted this, but just in case you check here first I'll ask the same question: how is the css class for body determined?
if it can be done programmatically you can use the code-behind of the Master Page for the template to set it so that it's handled automatically.
If this won't work, tell me more about how the css class is assigned and I will try to come up with an alternative.
hope this is helpful!
I have a page containing <div> tags with onclick="" code that calls an ajax request to get json data, and then iterates through the results to form links (<a />) to append to the page. These links do not exist in any other place on my website. How can I make these dynamically generated links crawlable?
My initial thought was to turn the <div> tags into <a> tags with a href="#", but with my limited knowledge of how typical crawlers work, i don't think this would solve my problem since the "#" would be what's recognized by the crawler, and not necessarily the dynamically generated output. This is besides the point that i don't want the scroll positioning to be altered at all, which would also rule out giving the <a> tag an id and having it reference itself.
Do I have any options aside from making a new page containing all of the links i need to be crawled? Thanks.
As a general rule, content that is created or made available through JavaScript cannot be found or indexed by search engines. Google does support crawlable Ajax but using it as the only means of accessing your content is bad for accessibility. Also, other search engines can't get to that content which is also not a good thing. Basically crawable ajax is a bad thing.
You should always make your content available without requiring JavaScript to get it. Then you can improve your site by adding JavaScript to make getting the content faster or easier. This is called Progressive Enhancement and is how good websites are built.
Context
Part of the administrator side of our application requires the user to edit various types of content, which involves using a rich text editor or using files to generate content that can be seen by the 'client side' users of the application. It's kind of a domain-specific CMS lite.
Because this 'content' can be used in various parts of the application, it is included as a seperate relation in some of our domain entities. We decided to make our own tag library that defines some form fields that can be used to edit this content when an administrator edits an entity that includes a piece of content.
Question
What we'd like to be able to do is the following.
<form:form modelAttribute=...>
<olo:content-editor path="content"/>
<!-- Other form fields for this entity -->
<form:.../>
<form:.../>
</form:form>
The olo:content-editor tag then generates a number of form fields based on what type of content is needed. This means it may (or, depending on the type of content, may not!) generate the filebased-content tag which contains:
<input type="file" name="file/>
Which can be used to replace the file associated with the file based content.
The problem is that the Spring docs indicate that the file upload requires the form to have the enctype to define that it's sending multipart form data. As the file upload is part of the tag and not the form itself, we find this is undesirable. We would like to be able to use our olo:content-editor tag in forms without having to change the form enctype attribute. Is this possible?
Possible solutions
We can think of two client-side hacks that may resolve our problem, but both seem to be rather ugly solutions:
Include a script in filebased content tag that changes the form enctype when it's loaded, so that it is always set to the appropriate type. (Very ugly.)
Submit the file data as a regular hidden form field, of which the data is set by using the HTML5 File API (administrators use a compliant browser. This seems far less ugly but still not an optimal solution.)