View Full Version : Help neede to make it work with frameworks like struts and codeigniter
gautammandewalker
12 May 2007, 9:44 AM
Hi,
I am trying to use ExtJS with Frameworks like Struts and Codeigniter.
I am very excited to use ExtJS for my applications built on these frameworks.
Can i get a small application like we have in the startup tutorial section for php and ASP.net,
for these two frame works.
tryanDLS
12 May 2007, 12:03 PM
No one here is just going to build an example of anything for you. That's what developers get paid to do. If you ask specific questions regarding integrating Ext with other frameworks, someone who has some experience with that may offer you some pointers. You have to make the effort to get started and understand what Ext does before you considering integrating with anything else.
dfenwick
12 May 2007, 12:28 PM
I've been watching a lot of the stuff that's been posted about using this framework or that framework and how to integrate Ext into those frameworks. Folks, Ext has nothing to do whatsoever with those frameworks. They are backend frameworks. There is absolutely nothing preventing you from using any backend framework you desire with Ext. All Ext expects is data in one format or another, typically either JSON or XML. You can build your Javascript completely independent of which backend you want to use. It does not have to be completely embedded in the framework, with the framework generating Javascript code for you.
Continue to use Struts, CodeIgniter, raw PHP, ASP.NET, ColdFusion, or whatever backend you care to use. Write your Javascript in their own files completely separate from your backend code. In whatever templates you use to deliver your HTML to the browser, just add the script and style tags you need to enable your Ext application. Then figure out the design for the data transfers for the data-enabled controls.
Sorry if it sounds like I'm picking on you, but this is really a design concept that people just aren't grasping. With Ext, your backend is going to be no more than a data delivery engine for your application. All of the really awful backend HTML templating and whatnot that people have had to endure for the last 10 years can simply be yanked out of the backend. All it needs to do deliver the initial application to the browser and then allow transfers in and transfers out from the XHR calls. With CodeIgniter, for example, the majority of the backend MVC for it is obsoleted by Ext. There is really no need for most of it. Some of the model code might still be relevant, but you're almost better off using Propel in lieu of the heftier MVC frameworks for PHP.
Instead of using Struts, you can use Jakarta modules like Torque to give you a generalized data backend and deliver that data over the wire with JSON or XML. There's no need to add another MVC to your Ext MVC. If you want to deliver state aware content pages to your ContentPanels, you can still use the backend MVC, but it's an awful lot of overhead that shouldn't really be necessary. Using the Ext templates, you can retrieve data from your web server and wrap it up right in Ext for display. Not only that, it's all data aware over XHR, so you can attach it to an UpdateManager object and the data 'just updates' on the page rather than having to do a full refresh of every page you generate at the server.
Someone's eventually going to have to write a paper about Ext application design principals. I may start authoring that after I finish part 2 of the Layout tutorial.
All it needs to do deliver the initial application to the browser and then allow transfers in and transfers out from the XHR calls.
You make an interesting point about how Ext is "supposed" to work. While you can use XHR for all page updates this may not always be the best case.
For instance, I am designing some fairly complex pages with paged grids, trees, nested border layouts, etc. For these I need to store the entire state server side so that pages are regenerated exactly as they were left by the user when they last finished with the page. While I could update state via XHR after the page load this may not be the most efficient option for fast loading pages. I can also rewrite the base Ext initialisation javascript server side before serving the page, so that it renders straight away with last saved state without any XHRequests. Or, slightly less efficiently, I can dump the state data as extra initialisation javascript to be run client side, again without any extra XHRs. Given this type of approach, there is a need to integrate dynamic Javascript generation server side. If using a framework then this will involve integrating it with the framework.
Max
dfenwick
18 May 2007, 10:03 AM
You make an interesting point about how Ext is "supposed" to work. While you can use XHR for all page updates this may not always be the best case.
For instance, I am designing some fairly complex pages with paged grids, trees, nested border layouts, etc. For these I need to store the entire state server side so that pages are regenerated exactly as they were left by the user when they last finished with the page. While I could update state via XHR after the page load this may not be the most efficient option for fast loading pages. I can also rewrite the base Ext initialisation javascript server side before serving the page, so that it renders straight away with last saved state without any XHRequests. Or, slightly less efficiently, I can dump the state data as extra initialisation javascript to be run client side, again without any extra XHRs. Given this type of approach, there is a need to integrate dynamic Javascript generation server side. If using a framework then this will involve integrating it with the framework.
Max
It still should require no integration of Ext with the framework. All your framework should really produce is a single set of javascript objects to represent your state and you then use those objects in your Ext application. This was the intention of using configuration options with the majority of the widgets. It allows you to pass configuration elements obtained from backend sources to your widgets for initialization and configuration. All the framework is generating is a single object (nothing to do with Ext) and sticking that in a set of variables available to pass to your initialization.
Generating javascript object data at the backend is a far cry from having to integrate the entire MVC of Ext into some other MVC model.
In theory, you are correct. It should be possible to use a single object. In practice I've found it doesn't really work out and you need to use two objects and two linked methods. One for initial configuration, and then one to restore state.
I don't have time just now to demonstrate this, but at some point I might try and produce a test case to show that using a single object/method combination is not possible. (Or someone can prove otherwise...)
Max
Hi,
I am trying to use ExtJS with Frameworks like Struts and Codeigniter.
I am very excited to use ExtJS for my applications built on these frameworks.
Can i get a small application like we have in the startup tutorial section for php and ASP.net,
for these two frame works.
There is one tutorial on integrating EXT with CodeIgniter here:
http://codeigniter.com/wiki/Using_CI_yuiyui-ext_and_MySQL_for_Ajax_Development/
However, the tutorial was intended for an earlier version of CodeIgniter and EXT. It does not consider the existence of user-contributed libraries developed after the tutorial was released or improvements to the CI framework. For example, it does not consider using something like the View library contributed by Coolfactor (which works extremely well with EXT layouts) or modular separation (allows CI to load module-like entities) contributed by Zawk.
Taking the Complex layout as an example using the View library for a Contacts component, one can disassemble Complex into CI component views, blocks (independent view fragments in CI lingo), and a master view (template).
The controller code might look something like this:
<?php if (!defined('BASEPATH')) exit('No direct script access allowed');
require(APPPATH.'libraries/application'.EXT);
// Application is a base controller extended from the CI Controller
// and includes globally accessible application code which can
// be inheirted by sibling controllers
class Contacts extends Application {
function Contacts()
{
parent::Application();
$this->lang->load('contacts', 'en_us');
}
function index()
{
$component = $this->lang->line('contacts_component');
$page = $this->lang->line('contacts_title');
$this->view->set('title', $page);
$this->view->part('west', 'west');
$this->view->part('north', 'north');
$this->view->part('tabpanel', 'tabpanel');
$this->view->part('component', $component);
$this->view->part('props_panel', 'props_panel');
$this->view->part('south', 'south');
$this->view->load('complex'); // the template
}
function getContacts()
{
// ... code to get contacts
}
function setContacts()
{
// ... code for a set contacts
}
}
?>
For the above controller, the main view or template (complex) would look something like this:
<html>
<head>
<title><?=$title ?></title>
<link rel="stylesheet" type="text/css" href="<?=js_url(); ?>ext/resources/css/ext-all.css" />
<!-- GC --> <!-- LIBS -->
<script type="text/javascript" src="<?=js_url(); ?>ext/adapter/yui/yui-utilities.js"></script>
<script type="text/javascript" src="<?=js_url(); ?>ext/adapter/yui/ext-yui-adapter.js"></script>
<script type="text/javascript" src="<?=js_url(); ?>ext/ext-all.js"></script>
<!-- ENDLIBS -->
<script type="text/javascript" src="<?=components_url(); ?><?=$comp ?>/views/js/component.js"></script>
<link rel="stylesheet" type="text/css" href="<?=templates_url(); ?>complex/css/template.css" />
</head>
<body>
<script type="text/javascript" src="<?=js_url(); ?>common.js"></script>
<div id ="container">
<?=$west ?>
<?=$north ?>
<?=$tabpanel ?>
<?=$component ?>
<?=$props_panel ?>
<?=$south ?>
</div>
</body>
</html>
The above view or template represents a variant of the EXT Complex layout disassembled into a set of view fragments or blocks of html. Absolute paths to EXT code, CSS and Javascript are handled using custom helper functions (js_url(), components_url(), templates_url). By breaking something like Complex into a collection of views, its possible to reorganize MVC application directory structures into logical groups (.i.e., storing component-specific views separate from standalone blocks (e.g., login, polls, syndication, and other blocks), and templates. That is, the associated PHP code for these entities is sometimes handled and stored differently based on view usage. Different flavors of views also have different caching requirements.
A lot of CI users favor using EXT, so it's not uncommon to find forum threads about using CI and EXT in conjunction on the CI forums. There is also a fairly recent fork of CodeIgniter called Kohana. CodeIgniter development is managed by EllisLabs, Inc., but Kohana development is handled using a community-driven approach.
openology
7 Aug 2007, 9:35 PM
A lot of CI users favor using EXT, so it's not uncommon to find forum threads about using CI and EXT in conjunction on the CI forums. There is also a fairly recent fork of CodeIgniter called Kohana. CodeIgniter development is managed by EllisLabs, Inc., but Kohana development is handled using a community-driven approach.
Could you point me to some resource covering codeigniter and Extjs. I did searches on both forum but uncovered limited information.
I planning to write a helper class to insert ext code into the view, if someone has already done that I like to take part in the effort rather than starting it fresh.
crafter
8 Aug 2007, 12:18 AM
Look at the coedigniter WIKI. You should be searching for YUI. Esra has provided a link is the post above.
Powered by vBulletin® Version 4.1.5 Copyright © 2012 vBulletin Solutions, Inc. All rights reserved.