I'm making components for a site and I'm wondering if I can return a cfform inside a return variable from a component and force coldfusion to output it parsed.
Obviously using "writeOutput(")" doesn't work.
How could I achieve this?
Thanks for your time!
You can't return a cfform, because tags can't be used inside of a CFScript based component. You're far better off doing something like this with a custom tag, which then references your component to get pieces to build out the form.
I would avoid (if at all possible) putting any cfform related pieces into a component, script-based or not.
If you did want to ultimately go this route, you'd need to put the cfform (and it's relevant pieces) either in another component that gets called by the script based one, or in an include that then is saved to a variable. All of the solutions related to trying to get the cfform into your CFC are going to be messy.
If you absolutely must do this (though I would shy away from it myself) you might want to have a look at this:
http://www.madfellas.com/blog/index.cfm/2011/1/26/Using-CFML-tags-in-cfscript-C4X-prototype
Related
i'm new in cakephp and I have started with version 3. I want to build a beautifull app and because I'm not good in design, I would really like to use a free template or buy one that I can use within cakephp.
So, I would really appreciate all your propositions and ideas or best practises. The easy way will be the best because I don't have a lot of time with this project. Thank you in advance.
If you don't have a lot of time like you mentioned, the easiest way to go ahead and get started is to paste a lot of the code in your default.ctp layout inside of src/Template/Layout/default.ctp.
You'll notice there are some lines of PHP already in there that are relevant to fetching blocks of css, meta tags, and other bits of code that could potentially exist throughout your project.
Find the main layout of the theme your trying to use - the one that will be consistent across most of the pages. That's the one you'll use for default.ctp. Compare what's already in default.ctp and make the comparable adjustments around the HTML in that document while keeping the important lines of PHP there as well.
For other important pages like a login or registration page, just create a new document for those, like 'login.ctp', then inside the function that loads the page (maybe 'login' inside of UsersController'), change the default layout with this line of code:
$this->viewBuilder()->layout('login'); // without the .ctp ending
This way you can create one-off layouts that don't really match any other page.
I am trying to learn Coldbox to perhaps replace the current framework I am using. One of the features that I currently use is the ability to override any of the template inclusions by convention.
Essentially, lets say I have a view, "views/home.cfm"
<h1>I am the default theme</h1>
and that is all well and good. But lets say that I have a different view, "themes/[theme-name]/views/home.cfm"
<h1>I am the user chosen theme</h1>
that I want to include conditionally (say there is a cookie to determine what theme is in use). Also, if the file does not exist, the default/fallback view should be rendered.
Is there any way of doing this overriding the system functions?
I looked at interceptors, and the preViewRender and postViewRender interceptors seem like the place to do something like this, but there doesn't seem to be any way of manipulating the actual workflow. If seems to be mainly pre/post processing of the content. For instance, there doesn't seem to be a way to "return false" to tell the renderView method to not actually render the view. Or any way to affect the location in which the view is to be found.
Any ideas?
Tyler,
The ColdBox Framework is quite flexible. It is possible to do what you desire but I don't think modifying renderView() is the best way to resolve this--although, you most definitely can.
I would encourage you to create a User Defined Function in the /includes/helpers/ApplicationHelper.cfm file that contains the logic you require. The functions that are added to this helper file are accessible from anywhere in the framework. This would allow you to create a function called "renderSkin()" that contains the logic you need. RenderSkin() would ultimitly call "renderView()" when you finally figured out which template you wanted to render for that user.
Respectfully,
Aaron Greenlee
I would suggest you go with the interceptor route, but change the layout instead of the view.
From the postEvent interceptor you can get the processedEvent key from the interceptData to change the layout.
Otherwise you could just make the check part of the layout page. The layout can the be a switch statement (or a more OO approach) $including the themed layout files as needed. This has the advantage of giving you a chance to emit custom interception points and having common functionality (css, js)
I've got an HTML table that lists a bunch of entries. I want to make the column headers clickable to be sorted. Problem is, I already have a bunch of filters in the URL (stuff like ?min_price=200&max_price=6000). How can I build the link such that it keeps these params in tact? Is there a function for it? Do I have to do it in the view?
Here's a cute trick I found that might do what you want:
http://andrewwilkinson.wordpress.com/2009/02/03/using-django-forms-for-get-urls/
Personally, I wouldn't do it that way.
I'd use Javascript and change the DOM directly.
You're not adding or removing any data if you are just sorting.
If you just change the DOM you'll possibly avoid calling the server, and the user experience will be better because you won't need to reload the screen.
In your template, you can add:
your_current_url?{{ request.META.QUERY_STRING }}
to pass the current query string params on to additional links.
Hope that helps!
I have a view called "contests_slider" with a block display. I'm hiding all fields and using a "Customfield: PHP code" field instead which calls a function called display_front_contests(). In that function, querying the database and building some html and returning it. I'm displaying the output in a block. The problem is Drupal is adding alot of extra divs that I don't want. I went to "Theme: Information" and copied the theme "views-view-field.tpl.php" to "views-view-field--contests-slider--block-1--phpcode.tpl.php" and put just: in it and it's still outputting all the extra html.
Any ideas? am I using the wrong template?
If you are only using views to create a block, but otherwise query the datebase, create the markup etc, you should consider making a block in a custom module. All the work is in the code you have already written. That way you wont have to think about the many templates that views uses, but instead you'll just use the block.tpl.php.
Take a look at hook_block for info on how to do it.
I'm developing a blog application using Django. Currently, the URL /blog/ displays the front page of the blog (the first five posts). Visitors can then browse or "page through" the blog entries. This portion is mapped to /blog/browse/{page}/, where page, of course, is an integer that specifies which "page" of blog entries should be displayed.
It's occurred to me, though, that perhaps the "page number" should be an attribute of the querystring instead (e.g., /blog/browse/?page=2), since the content of the browse pages is not static (i.e., as soon as I add another post, /blog/browse/2/ will have different contents than it had before the post was added). This seems to be the way sites like Stack Overflow and Reddit do things. For example, when paging through questions on Stack Overflow, a "page" attribute is used; likewise, Reddit uses a "count" attribute.
Extending this thinking, I realize that I use the same template to render the contents of both /blog/ and /blog/browse/, so it might even make sense to just use a URL like /blog/?page=2 to page through the contents of the blog.
Any suggestions? Is there a "standard" way of doing this, or at least a "best practice" method to use?
For my money, the best general purpose approach to this issue is to use the django-pagination utility. It's incredibly easy to use and your URLs should have the format you desire.
I prefer to use the GET URL parameter, as in URL?pg=#. It's very common and provides a standard visual clue to users about what is going on. If, for instance, I want to bookmark one of those pages or make an external link, I know without thinking that I can drop the pg parameter to point at the "latest" front-page index. With an embedded #, this isn't as obvious... do I leave off the parameter? Do I always have to set it to 1? Is it a different base URL entirely? To me, having pagination through the GET parameter makes for a slightly more sensible URL, since there's an acceptable default if the parameter is omitted and the parameter doesn't affect the base URL.
Also, while I can't prove it, it gives me the warm fuzzy feeling that Google has a better chance at figuring out the nature of that page's content (i.e. that it is a paginated index into further data, and will potentially update frequently) versus a page # embedded inside the URL, which will be more opaque.
That said, I'd say this is 99% personal preference and I highly doubt there's any real functional difference, so go with whatever is easier for and fits in better with your current way of doing things.
EDIT: Forgot to mention that my opinion is Django specific... I have a few Django apps so I'm relatively familiar with the way they build their URLs, and I still use a "pg" GET parameter with those apps rather than embedding it in the URL directly.
It seems like there are two things going on. A static page, that won't change and can be used for permalinking, like an article, as well as a dynamic page that will update frequently. There is no reason you cannot use both. URL rewriting should allow this to work quite nicely. There's no reason to let the implementation control the interface, there is always at least one way to skin every cat.