I want to design a web album with every image in the album having it's own title, and description. So, at a time only one set of image, title and description would be visible. And on clicking next button, the next set of image, title and description would appear,and so on.
So am wondering, what would be the best way to design with? HTML or AJAX?
I don't want to use the ready to use tools such as lightbox.
Do you want the browser's back button to work? If so, then you should make your life simple
and use html (since you will only be displaying one image at a time either way).
Ajax implies using html. On the other hand, using html does not necessarily imply that you need to use AJAX to load content dynamically.
What is the purpose of this project? If you are doing it for the learning experience you should go on with AJAX (from scratch). If you want speed and quality use an existing web image gallery. If you need to write it yourself use plain html (or an ajax framework such as dojo, jquery, etc. this will save you a lot of pain solving cross-browser quirks).
In addition, if you want to be able to click a button to take you to the next (previous) image
and you don't know how many images you will have beforehand, then you are looking for dynamic behavior. You can code dynamic logic either on the client side (javascript), or on the server side (let's say "php" to start with).
Also, how do you plan to keep the corresponding (image, title, description) together?
If you only have a 3 images, say you could hard code each of this into its corresponding html file. eg. 1.html, 2.html, 3.html. Then you would have to point the forward button from a.html to point to b.html. etc...
If you didn't want this boring static behavior and wanted something smarter, say you decided for AJAX. Then you would only have 1.html file and from there (using javascript) you would ask your server for the (image, title, description) and load all that (dynamically, without refreshing the browser) into the same page. The easiest way to get this from the sever is by just reading a a static (XML, or JSON) file which contains all the info (image urls, titles, descriptions). Then with javascript and using DOM manipulation you would remove the old image, and add the new one.
However, this would all be a lot simpler with server-side processing (and it's worth learning). In this case you could have a url which takes a parameter with the image number. eg. http://example.com/gallery/index.php?image=X
then before the server responds to the client with the html, it would realize that you want to load image X so it would get it's corresponding description, title, and url. and "embed" those into the file. Of course, depending on the number, it would also add the right links for the previous and next buttons. Eg. If the currently displaying image was 9 then forward button would "dynamically" be determined to link to (X+1) : http://example.com/gallery/index.php?image=10
Related
I am reluctant to post this, but I am having trouble understanding how markdown actually "saves" to a database.
When I'm creating a migration, I will add columns and specify the type of value (i.e. integer, text, string, etc.) and in the course of operation on the website, users will input different information that is then saved in the DB. No problem there.
I just can't seem to wrap my head around the process for markdown. I've read about saving the HTML or saving the markdown file, rendering at runtime, pros and cons all that.
So, say I use an editor like Tiny MCE which attaches itself to a textarea. When I click "Submit" on the form, how does that operate? How does validation work? Feel free to answer my question directly or offer some resource to help further my understanding. I have an app built on Laravel so I'm guessing I'll need to use a package like https://github.com/GrahamCampbell/Laravel-Markdown along with an editor (i.e. Tiny MCE).
Thanks!
Let's start with a more basic example: StackOverflow. When you are writing/editing a question or answer, you are typing Markdown text into a textarea field. And below that textarea is a preview, which displays the Markdown text converted to HTML.
The way this works (simplified a little) is that StackOverflow uses a JavaScript library to parse the Markdown into HTML. This parsing happens entirely client side (in the browser) and nothing is sent to the server. With each key press in the textarea the preview is updated quickly because there is no back-and-forth with the server.
However, when you submit your question/answer, the HTML in the preview is discarded and the Markdown text from the textarea is forwarded to the StackOverflow server where is is saved to the database. At some point the server also converts the Markdown to HTML so that when another user comes alone and requests to view that question/answer, the document is sent to the user as HTML by the server. I say "at some point" because this is where you have to decide when the conversion happens. You have two options:
If the server converts the HTML when is saves it to the Database, then it will save to two columns, one for the Markdown and one of for the HTML. Later, when a user requests to view the document, the HTML document will be retrieved from the database and returned to the user. However, if a user requests to edit the document, then the Markdown document will be retrieved from the database and returned to the user so that she can edit it.
If the server only stores the Markdown text to the database, then when a user requests to view the document, the Markdown document will be retrieved from the database, converted to HTML and then returned to the user. However, if a user requests to edit the document, then the Markdown document will be retrieved from the database and returned to the user (skipping the conversion step) so that she can edit it.
Note that in either option, the server is doing the conversion to HTML. The only time the conversion happens client-side (in the browser) is for preview. But the "preview" conversion is not used to display the document outside of edit mode or to store the document in the database.
The only difference between something like StackOverflow and TinyMCE is that in TinyMCE the preview is also the editor. Behind the scenes the same process is still happening and when you submit, it is the Markdown which is sent to the server. The HTML used for preview is still discarded.
The primary concern when implementing such a system is that if the Markdown implementation used for preview is dissimilar from the implementation used by the server, the preview may not be very accurate. Therefore, it is generally best to choose two implementations that are very similar or, if available, use the same implementations for both.
It is actually very simple.
Historally, in forums, there used be BBCodes, which are basically pseudo-tags that allow you to format your text in some say. For example [b][/b] used to mean "make this text bold". In Markdown, it happens the exact same thing, but with other characters like *text* or **text**.
This happens so that you only allow your users to use a specific formatting, otherwise if you'd allow to write pure HTML, XSS (cross-site scripting) issues would arise and it's not really a good idea.
You should then save the HTML on the database. You can use, for example, markdown-js which is a Markdown parser that parses Markdown to HTML.
I have seen TinyMCE does not make use of Markdown by default, since it's simple a WYSIWYG editor, however it seems like it also supports a markdown-like formatting.
Laravel-Markdown is a server-side markdown render helper, you can use this on Laravel Blade views. markdown-js is instead client-side, it can be used, for example, to show a preview of what you're writing in real-time.
I would like to send a lot of data through ajax request to my server which will generate pdf or jpg format according to that data.
Now i have done all that, my issue is to how output that generated pdf/jpg back to the user trough ajax? I guess i might be able to use json for that, but im not really sure how, and i think there would be a lot issues with pdf.
Also if some one gonna suggest using form with hidden inputs that will not work since i have really big multidimensional array with lot's of data and it would simply take to much effort to make it work.
By the way, i am using jquery, but anything else is acceptable as long as it does the job done without making me to rewrite half of my script.
To display a JPG
AJAX: You can return the data hex encoded (be sure to set the content type appropriately: header('Content-type: image/jpeg')). Then you just inject an <img/> element into the DOM and set it's src attribute to the returned Data URI.
HTML: Also, you could inject the <img/>'s with a normal src URL to some location on your server.
For PDF
It's a little more tricky. Some browsers display PDF's natively (Chrome/Firefox), others rely on optional third-party plugins. You can detect these plugins, but can't control whether the PDF is displayed in a window/frame or is downloaded.
If you choose to display, you can create a new window/tab to display it or display it in an iframe dynamically.
I'll admit that I'm pretty new web development (only been coding for about a year) and especially green when it comes to JS / jQuery.
A specific web page I've built loads different data based on hovering over certain categories: country clubs, resorts, hotels, etc. When I built the site on my local machine, the javascript function was super quick. However, on the live site, it has a long delay before the data swap happens.
The URL is: http://preferredparkingsolutions.com/client_list.html
Which links to a javascript function at: http://preferredparkingsolutions.com/scripts/clientHover.js
Which replaces the display div (#client_list) by pulling data from a text file.
Is there a better / faster way of doing this?
Yes, this could be optimised by loading the content in up-front and caching it. Currently you are doing a HTTP request each for each and every hover - even if the user has hovered over that element before, since the AJAX responses aren't being cached. Doing this would be your quickest win.
However, I can't see any case at all for having the content live externally. Is there any reason you're against having the content physically in the page and just using show/hide methods? There's various benefits to this - SEO, for one thing, since Google will find the content.
this is the external page you are loading http://preferredparkingsolutions.com/client_list.inc.html and the content looks little and looks like its a static page then why not just load every thing upfront and then just hide and show div's ? as Utkanos suggested you will aslo have a SEO benifit and also its HTTP request each for each and every hover. if you still want to load it externally lost load it once and cache it and use the cached version to hide and show divs.
I have a website made to provide free web-based tools for making indie games. Currently, it only supports artists contributing to games. The features for helping artists consist of a set of artist community tools that allow artists to upload images based on a description, then we post that image in a gallery page. Other artists can upload their images and each image can have several revisions.
The way I chose to implement the image upload and display feature is by serializing uploaded images to a byte array and storing it in the database. When I need to display the image in the UI I just call a controller action I named "GetScaledGalleryImage" and pass in the image ID. That controller action takes the binary from the database and converts it back into an image, returning the requested image back.
This works very well functionally, but the problem I realized later is that the google crawler thinks all of my images are named "GetScaledGalleryImage" so if someone searches for "sylph" on google images, nothing comes up from my site, but if someone searches for site:watermintstudios.com getscaledgalleryimage, all of my images come up.
Here is an example of the URL that is being output in my HTML http://watermintstudios.com/EarnAMint/GetScaledMedia/68?scale=128
In the past, pre-MVC I would handle 404 errors and return content based on what was requested even if the page didn't actually exist. This would of course allow me to have the images pulled back by the image name (or description).
Is that the best way to do this? Or is there a better option? Something simpler would be better like if I could just do http://watermintstudios.com/EarnAMint/GetScaledMedia/Iris%20Doll?id=68&scale=128, but based on how google indexes images, would that give me what I need? Or do I need to provide image file extensions for maximum indexability?
Thanks all
It is important when doing Search Engine Optimization to always use alt="this is a crazy robot" for your images. This will help the crawler identify them. Note: always use alt, don't always name your images this is a crazy robot.
I'll explain:
I have a picture gallery, the first page is display.php.
Users can flip through pictures using arrows, when you click an arrow it sends an Ajax request to retrieve the next picture from the db. Now I want the URL to change according to the picture displayed.
So if the first picture is:
www.mydomain.com/display.php?picture=Paris at night
I'll flip to the next one and the URL would be
www.mydomain.com/display.php?picture=The Big Ben
How do I do this?
The trick here are uri's with an anchor fragment.
The part before '#' points to a resource on the internet, and after normally designates to a anchor on the page.
The browser does not refresh if the resource is the same but moves to the anchors position when present.
This way you can keep the convenience of browser history from a usability point of view while replacing certain parts on the page with ajax for a fast and responsive user interface.
Using a plugin like jQuery history (as suggested by others) is really easy: you decorate certain elements with a rel attribute by which the plugin takes care of the rest.
Also kinda related to this topic is something called 'hijax', and it's something I really like.
This means generating html just like you would in the old days before ajax. Then you hijack certain behavior like links and request the content with ajax, only replacing the necessary parts. This in combination with the above technique allows really SEO friendly and accessible webpages.
You can use the jQuery history plugin for example.
changing the search of the url will load the changed url.
See also: stackoverflow, javascript changing the get parameter without redirecting
Do you really want to use AJAX here?
A traditional web request would work like this...
User navigates to display.php
User clicks "next" and location is updated to "display.php?picture=Big-Ben"
Big Ben is shown to user, along with a link to "display.php?picture=Parliment"
User clicks "next" and location is updated to "display.php?picture=Parliment"
And so on.
With AJAX, you essentially replace the GET with a "behind the scenes" GET, that just replaces a portion of your page. You would do this to make things faster... for example...
User navigates to display.php
User clicks "next" and the next image location is obtained using an AJAX request
The image (and image description) is changed to the next image
What you are suggesting is that you retrieve the "next url" using AJAX and then also perform a GET on the whole page. You would be much better off sending the "next" image when you send each page and not using AJAX at all.
this best describes everything i think: http://ajaxpatterns.org/Unique_URLs