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.
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 capable with PHP, HTML, CSS, JavaScript and SQL, and not bad with Drupal. Very recently, I acquired a customer that wants me to do some SocialEngine 4.xxx customization. My customer is aware that I have no experience with SocialEngine, but am capable with the underlying technologies (I gave him a lower hourly rate because of this too.)
I'm not seeing very much online that is geared towards someone like me. Where can I read about modifying SocialEngine that assumes very little knowledge about SocialEngine, but a competency at programming?
For example, I spent a few hours today trying to figure out how to conditionally display a block based on a Membership Level. It appears there is no way to do this using the GUI. No problem, I found some code that seemed like I could get it to work that would grab the user's membership level. However, where do I put this? Honestly, I'd like to have this at the block-level. SocialEngine doesn't seem to allow me to place arbitrary PHP code into a block, and even if it did, would that be the "SocialEngine" way of doing this? Should all custom logic like this be a module in SocialEngine, that attaches to events using hooks?
Thank you very much for looking at my question,
-Brian J. Stinar-
I've written a blog about accessing data through models, creating widgets and modules. You can find out about the general structure of Social Engine at http://garbtech.co.uk / http://socialenginetutorials.co.uk (both same blog)
Unfortunately, there are no books or official documentation on SocialEngine PHP API. Your only choice is to check out various (incomplete) guides over the Internet or study their source code and figure things out by yourself.
So, I've been trying to clean up my code and learn things that I should always do...well of course server-side validation is one of those things that I should always do. However, what happens when I have this huge form? I really would like to have a generic function that allows me to pass the data type and field name. Is there a secure way to do this in Coldfusion?
I've been looking into doing this for a while, but I've come to dead ends and can't find any info on doing something like this on the web. It seems like Coldfusion does not offer this ability.
However, I think it would be cool if there was a way to specify an attribute in your input tags that had the data type of the field. Then, it would be uber nice if Coldfusion stuck it into a struct for you with your field names.
Is there anyway to accomplish this or can someone elaborate on the most efficient way to do server-side validation?
That would be great if CF had something like that! Good news, it does, for years now! :)
What you're looking for is cfinput (and cfform) tag. This tag includes the validation specifics right in the tag like you're wanting (great minds think alike, right?). You can specify the validation, the error message, if it should validate client or server side - all kinds of neat tricks.
Check here for implementation - it's quite easy to use:
http://livedocs.adobe.com/coldfusion/8/htmldocs/help.html?content=Tags_i_07.html
Be warned that a lot of code diva's hate cfform / cfinput. In reality, there is nothing wrong with them when implemented correctly. It can be abused and it won't fit for every solution, but that is true of everything in the toolbox. By and large, for most form input and validation situations it works great.
If you hate that idea, another is to use the built in type attribute of cfparam and catch your errors.
For example, at the top of your form processing page, you can :
<cfparam name="form.cardNumber" type="creditcard">
When this is reached, if the value in that variable is not of that type, it will throw an exception that you can catch. This keeps you from having to write the if() and pattern matching. Additionally, if there isn't a type built in, you can specify a regular expression for pattern matching.
Here's some more information and the types supported:
http://livedocs.adobe.com/coldfusion/8/htmldocs/help.html?content=Tags_p-q_01.html
Let me know what you think!
I would encourage you to look at possibly using a ColdFusion framework like CFWheels (or ColdBox) which has a lot of this type of functionality already built in to make development a TON easier. Using CFWheels has been one of the best decisions I've made as a developer and my development skills have grown significantly over the past year. There's some great screencasts online to get started. http://cfwheels.org/screencasts
I have a service that receives an object containing all the data needed to build a newsletter. I need to be able to generate the email using different templates.
I don't want to involve the whole ASP.NET stack for that, so I want a separate templating engine.
Reading a lot of opinions, I have found that XSLT was not getting very much love when it comes to templating engines. Why?
SparkViewEngine is a "new cool toy", but it seems mature enough considering the number of projects that have been built with it. What do you think?
Did you used those 2 engines? in which situation, and what strength/pain did you enjoy/endure
XSLT is much more verbose, especially when it comes to tricks like conditional attributes. I used it a lot (even to generate C#/C++ source code) but I don't remember that time to be a joy. Spark is.
I used a Spark template to generate an email on my last project, it was a fairly straight forward experience.
As you mentioned you have an object containing all the data needed to build a newsletter. To use XSLT wouldn't you need to serialize to to XML first? Using Spark skips the serialization step and gets you directly to the output you want, and as queen3 mentioned, creating conditional attributes is quite easy.
In case you need it, there's a post on how to use Spark as a general purpose templating engine here.
Also if you have to work with any graphics designers it may be easier to take an HTML mockup and turn it into a spark template than it would be taking an HTML mockup and turning into an XSLT.
i have a big web application running in perl CGI. It's running ok, it's well written, but as it was done in the past, all the html are defined hardcoded in the CGI calls, so as you could imagine, it's hard to mantain, improve and etc. So now i would like to start to add some templating and integrate with a framework (catalyst or CGI::application). My question is: Somebody here has an experience like that? There is any things that i must pay attention for? I'm aware that with both frameworks i can run native CGI scripts, so it's good because i can run both (CGI native ad "frameworked" code) together without any trauma. Any tips?
Write tests first (for example with Test::WWW::Mechanize). Then when you change things you always know if something breaks, and what it is that breaks.
Then extract HTML into templates, and commonly used subs into modules. After that it's a piece of cake to switch to a framework.
In general, go step by step so that you always have a working application.
Extricate the HTML from the processing logic in the CGI script. Identify all code that affects the HTML output, as these are candidates for becoming template variables. Separate that into a HTML file, with the identified parts marked with template variables. Eventually you will be able to refactor the page such that all processing is done at the start of the code and the HTML template just called up at the end of all processing.
In this kind of situation, rewriting from scratch basically, the old code is useful for A) testing, and B) design details. Ideally you'd make a set of tests, for all the basic functionality that you want to replicate, or at least tests that parse the final result pages so you can see the new code is returning the same information for the same inputs.
Design details within the code might be useless, depending on how much the framework handles automatically. If you have a good set of tests, and a straightforward conversion works well, you're done. If the behavior of the new doesn't match the old, you probably need to dig deeper into the "why?" and that'll probably be something odd looking, that doesn't make sense at first glance.
One thing to remember to do first is, find out if anyone has made something similar in the framework you're using. You could save yourself a LOT of time and money.
Here is how I did it using Python instead of Perl, but that should not matter:
Separated out HTML and code into distinct files. I used a template engine for that.
Created functions from the code which rendered a template with a set of parameters.
Organized the functions (which I termed views, inspired by Django) in a sensible way. (Admin views, User views, etc.) The views all follow the same calling convention!
Refactored out the database and request stuff so that the views would only contain view specific code (read: Handling GET, POST requests, etc. but nothing low-level!). Relied heavily on existing libraries for that.
I am here at the moment. :-) The next obvious step is of course:
Write a dispatcher which maps URLs to your views. This will also lead to nicer URLs and nicer 404- and error handling of course.
One of the assumptions that frameworks make is that the urls map to the code. For example in a framework you'll often see the following:
http://app.com/docs/list
http://app.com/docs/view/123
Usually though the old CGI scripts don't work like that, you're more likely to have something like:
http://app.com/docs.cgi?action=view&id=123
To take advantage of the framework you may well need to change all the urls. Whether you can do this, and how you keep old links working, may well form a large part of your decision.
Also frameworks provide support for some sort of ORM (object relational mapper) which abstracts the database calls and lets you only deal with objects. For Catalyst this is usually DBIx::Class. You should evaluate what the cost of switching to this will be.
You'll probably find that you want to do a complete rewrite, with the old code as a reference platform. This may be much less work than you expect. However start with a few toy sites to get a feel for whichever framework/orm/template you decide to go with.