I need advice - what technology I could use to create website form to merge 2 images [take from list] and one text from text field?
I want to see results on same page.
I see two possible solutions.
First, using pure javascript and canvas:
I saw simillar problems here and here.
Authors use pure javascript and DOM to manipulate with html5 Canvas.
So problem is to draw images on context, and also insert text.
To insert text, there is method fillText, i am not sure it would look great for first time, but studying canvas should solve problem.
So HTML5 Canvas is first answer.
pros:
easy to implement and only javascript
cons:
may not fit your needs as application grows up.
Second, according to fact, that there may be some limitations, eg.
your picture must be on same domain as your application
you want to do something more difficult with images and text
then you may use server side application, and work with server side graphic library.
It may be for example PHP GD, for php.
Here is possible solution in php.
The application may look like:
obtaining data with a form ( uploading images from disc, filling textfield )
after clicking submit, do an AJAX POST call with multipart-form-data to php page
receive an resulting image in ajax response.
pros:
can solve more difficult tasks, for which your application may
evolve.
cons:
there are two languages to learn - php and javascript.
it may be difficult to send two images to php script at one time and
text, but it's possible
The first solution is less complicated and you can test code adhoc, but second solution is more demanding, but you can reach better result and have more robust technology.
Related
I’m writing a web application in Perl. It has a form containing contact information, and is currently laid out something like this:
$form_htm = <<EOF
<input value="$in{firstname}" name="firstname">
<input value="$in{surname}" name="surname">
...etc...
EOF
Later on I print $form_htm (amongst other things) to display the webpage.
The above is working for me, and the fields are interpolated as expected.
However, I’d like different organisations who use this application to be able to have a different layout for their fields. Some fields won't apply to some organisations, and some organisations will want different sizes (on the web page) for fields than others.
So, I thought I’d store the HTML for the form in a database (different versions in different records for different organisations).
But because the HTML is not stored in the script, the fields (like $in{firstname}) are not interpolated, so the variable names themselves are ending up on the web page, (which is not quite the look I’m after).
Any recommendations on how I should get these variables to be evaluated in this context? (First thing that came to mind is eval(), but that seems aimed at evaluating expressions, not variables mixed in with a lot of other text.)
Or can you suggest a better approach to allow for different form layouts for different organisations?
Edit: I have also posted this question on Perl Monks, but would like to get other opinions.
Here's some bad ways and some good ways to handle this.
The Bad Ways
Stick HTML in your code.
my $form_htm = <<EOF
<input value="$in{firstname}" name="firstname">
<input value="$in{surname}" name="surname">
...etc...
EOF
This was a very common thing to do. It has major problems. First, it welds together the logic of the program with what is displayed. There's either only one way to display it, or your code gets increasingly complicated trying to allow multiple ways to display it. You're running into this problem.
Second, it means in order to change how it looks you need a developer involved. You can't have separate UX people working on the HTML and CSS layout, they also need to know Perl or get a Perl developer involved. This makes it very expensive and slow to make otherwise simple HTML changes.
Third, with the code to generate the HTML scattered around it makes it difficult to figure out how each page comes to be. If you want to change a form in a page, you have to hunt around in the code to find how it's generated.
Fourth, it's slow. Every single page has to be generated by the server.
Stick code in your HTML.
<%class>
has 'amount';
has 'name';
</%class>
Dear <% $.name %>,
We are pleased to inform you that you have won $<% sprintf("%.2f", $.amount) %>!
Sincerely,
The Lottery Commission
<%init>
die "amount must be a positive value!" unless $.amount > 0;
</%init>
This what PHP and Mason do. It's better than sticking HTML in your code, but it still has major problems. It can be used well, but it encourages you to put WAY too much logic into the templates. This scatters the logic around making it hard to understand what's going on. Code in the templates is hard to document and test. It also mixes code into the templates which again blurs the line between UX person and developer.
The Good Ways
MVC: Model-View-Controller
Model-View-Controller provides a clear delineation between the data and logic (the "model") and how it's displayed (the "view"). These are connected with a bit of code to get data from the model and send it off to the view as variables (the "controller").
This is one of the most successful ways of putting together a web site. Ruby On Rails and Catalyst are built around this.
I'd recommend Dancer. It's much smaller and easier to understand than Catalyst. Since it provides less it's easier to adapt an existing program to use it. It provides the view and controller, the model is up to you.
There's two good ways to put together the view.
An HTML Template.
The usual way is to put your entire HTML page in a template, much like we saw before, but instead of it having its own code for getting data it's instead passed data to use. It has a limited language for manipulating that data.
In Perl this is generally Template Toolkit.
Dear [% name %],
It has come to our attention that your account is in
arrears to the sum of [% debt %].
Please settle your account before [% deadline %] or we
will be forced to revoke your Licence to Thrill.
The Management.
Now UX people can manage HTML templates on their own. They still have to learn a template language, but it's at least a well documented one. The limited language discourages putting too much code in the templates creating a sort of firewall between the View and the rest of the code.
But all the work to format the template still must be done on the server side. And UX people still have to learn a special template language. Which brings us to the best way.
Pure HTML, CSS, and Javascript.
In this mode, instead of processing a template on the server side and inserting variables into it, the HTML has Javascript which requests the data it needs and displays it as it sees fit. This has great advantages.
It completely divorces the view from the rest of the code. This gives the UX folks great control over how the application behaves. They decide what data each page needs. They decide how it's manipulated and displayed. Developers can focus on providing the data.
The other advantage is using Javascript. Javascript has become the defacto programming language that web designers must know. UX folks don't need to learn a special template language, they use the same HTML, CSS, and Javascript they've always used.
Finally, this means the bulk of the formatting work is done on the client side reducing the load on your server.
The main disadvantage is this requires a major re-architecture of an existing system. Instead of producing HTML pages, your server code now produces JSON for the Javascript to manipulate via REST requests.
Hybrid Template + Javascript
A good hybrid for an existing system is to use templates, but instead of using a special template language, use Javascript. Simple scalar variables like names and amounts can still be provided as template variables, but larger units like lists and hashes are injected into the template as JSON.
For example, this template...
var people = [% people %]
would be provided with people = encode_json(\#people)' and it might expand to:
var people = ["Jack", "Jill", "Jane", "Joe"]
Then the UX person can do whatever they want with this Javascript people array.
On the downside, this still gives the developers too much control over how the site works, because they decide what templates are used and what data they're given, and it still means the templates have to be expanded server side.
On the upside it lets UX people manipulate that data in ways they're comfortable with, it enforces a clear separation between the view and the rest of the code, and you can convert existing code to use these sorts of templates a piece at a time.
I am fairly new to laravel. I am learning it's various components gradually. I was going through one of the tutorials where I found 'Form and Html Facade'. I understand that it automates a few lines of code for us and makes the process faster but does it offer any other advantage apart from this?
Also, I saw we could direct the form to some specific method of a controller on submission. Can we do the same without using a facade too? If yes, please show an example , so that I may follow.
Actually, I have a web-designer's background and I am much more comfortable coding in raw HTML and CSS . So, If I am sure about not missing out some great laravel-tool, I can happily continue with raw HTML codes.
I'm designing a multiplayer poker site and require a way to display changes that occur during game play on all users screens that are active at the table including Ai decisions?
I'm coding using the MVC Structure, and currently making use of C#, javascript and html5
I've attempted using meta tags
and javascript intervals, but unfortunately all it does is continuously refreshes the entire screen, even when partial views are used
I'm looking for something to maintain real time gameplay
I suggest You look into JavaScript JSON or Ajax controls.
Meta tags won't help as they as designed to refresh the entire page and you often see the lag of loading the page between IE9 and Google Chrome. That would definitely adversely affect your multi-player environment.
Stick with the partial view, because that is the way to go, but in your view have a Ajax function, datatype:json , type:post, and use the success of the function to do whatever process is required.
I am starting a new project where we need to make entering web data forms an easy experience on mobile.
Currently our web site data forms cannot be styled and made mobile friendly they also reside behind a company firewall, however we can do POSTS via XML to submit a data form.
I'm currently undecided to which approach would be best.
Rebuild the forms natively on the iPhone using iOS components
Somehow create a local HTML5 Data form on the mobile, and then have the iPhone parse this and submit via XML.
Has anyone done similar on mobile in the past, it would be great to hear of your experiences, one key piece to this project is that we also need to have the data forms offline, and have them posted when the device is back online.
Based on the background information you've given, I believe that the only way to go is with the native UI components. Here's why:
You've stated the need for offline form "submission". You will have a much easier time if you have a native form that stores the information somewhere and then submits it when connected.
You've stated the desire to provide an easy experience on mobile. For that, I would naturally recommend native UI controls. Your custom "native" web controls are more likely to be confusing and difficult to use. Contrast that with UIKit which presumably has a lot of research behind it (and millions of satisfied users to back it.)
In the long run, it will be easier to integrate with the rest of the device if you use native controls.
For making XML requests, I recommend the ASIHTTPRequest library.
In my opinion, the better option would be to recreate the forms using the iOS components. It would be much more user friendly, and faster, if done right.
I am considering making use of GWT as the front-end to an existing web application.
I can't justify a complete rewrite to 100% GWT in one go. It is likely that I would migrate parts of the system to GWT gradually. However for consistency I would like to make use of the GWT TabPanel, MenuBar, etc as global interface elements from day one.
As an experiment to see how 'legacy' parts of the system could be incorporated, I have done the following.
The application's main page template now loads a small 'wrapper' GWT module on every page. This GWT module looks for a selection of DIVs in the dynamically generated host page. If the DIV is found, a suitable widget is slotted into place, i.e. menuBar, tabPanel.
A lot of the configuration for the included widgets can also be slotted into the host page as JSON structures. For instance, I have implemented an adapter that dynamically sets up a TabPanel in this way. I've also added some very simple widgets that load remote HTML, etc.
As a prototype, this all appears to work perfectly and loads quickly.
However, it seems that GWT apps are really designed to be run from a single host page, not hundreds of dynamically generated ones.
Can anyone highlight any issues that the above approach may run into, particularly as the GWT module increases in size? I would aim to keep the legacy wrapper module intentionally lean. Other functionality would be implemented in separate modules.
How have other people integrated GWT into their front end in a gradual fashion?
One of the ways GWT was designed to be used is exactly as you've used it. We have done that in many of our apps - where there is one GWT module with multiple 'parts' that are loaded based on whether a given id exists on a page or not. So I don't see that you'll have any issues at all going this way. We often use this approach even for new web applications, where we just want a few 'widgets' on the page, rather than coding the whole application in GWT.
It won't make a huge difference, but one thing I would suggest is not putting the GWT javascript code into your main template, but rather only put it on the pages that need it. It's true that if you're not running HTTPs it is cached basically forever, but it seems wrong to get people to load in the module if it's not actually needed on that page. This of course depends on how people use your site, if they are likely to download it anyway then it won't make any difference.
You're doing it right. Avoid avoid avoid the temptation to try to 'minimize' the GWT footprint by breaking it up into multiple separate apps.
The key to GWT performance is to have as few downloads as possible and to make sure they're cached. Loading a 250k bundle once is much better than two 200k bundles and because compression get's better with larger files you really start to reap benefits as things grow.
y-slow & firebug can be really helpful when it comes to convincing yourself of this.
One performance trick you might check out is available in the sample chapter here: http://www.infoq.com/articles/progwt
It shows a mini-architecture around loading GWT widgets into any number of slots and pre-populating data in JavaScript variables. This allows your GWT widgets to load and not require a second HTTP GET to get the data they use. In practice I found that this was a nice performance boost.