> I'm discovering the file upload feature provided by the framework.
> I'm wondering is there a way not to put the uploaded file on disc
> but to keep it in memory until it's transfered to the databases ?
how large are your files?
why do you want to put your files to db?
Marco Pracucci
Interesting to see all the command line params mixed as part of the
dependency objects ... I've only used that for kwArgs buildExclude
stuff. Would definitely cleanup some command lines of mine if I started
doing it this way :)
Matthew Weier O'Phinney wrote:
> -- Drew Bertola <drew@drewb.com> wrote
> (on Saturday, 27 December 2008, 10:55 PM -0800):
>
> * Create a layer file that contains all your dojo.require() statements:
> In public/js/<your custom module>/main.js (I'll call it "custom"):
>
> dojo.provide("custom.main");
>
> (function(){
> dojo.require("dijit.form.Form");
> dojo.require("dijit.form.Button");
> /* etc. */
> })();
>
>
Just as a note, put the dojo.require calls above the closure, and use
the anon function to scope stuff locally for that module. When the build
runs, executing the code from form.FOrm and form.Button within the
(function(){ })() is unnecessary overhead (though trivial). It also
seems "cleaner" to me:
dojo.provide("my.thinger");
dojo.require("my.otherthinger");
(function(){
// do stuff
var d = dojo; d.addOnLoad(function(){ ... });
})();
The way the build works (in the x-domain case) may be affected if the
require calls are not "outside" of the closure there, as special
consideration in the loader is taken to ensure all the modules are
tracked synchronously and whatnot.
> * In your bootstrap, make sure you reference this layer file:
>
> $view->dojo()->requireModule("custom.main");
>
> * Create a profile: public/js/util/buildscripts/profiles/custom.profile.js
>
> /* ./build.sh profile="custom" */
> dependencies = {
> action: "release",
> version: "1.2.2-custom", /* this can be arbitrary */
> releaseName: "custom",
> loader: "default",
> cssOptimize: "comments.keepLines",
> optimize: "shrinksafe",
> layerOptimize: "shrinksafe",
> copyTests: false,
> layers: [
> {
> name: "../custom/main.js",
> layerDependencies: [],
> dependencies: [
> "custom.main",
> ]
> }
> ],
> prefixes: [
> [ "dijit", "../dijit" ],
> [ "dojox", "../dojox" ],
> [ "custom", "../custom" ]
> ]
> }
>
> * From within public/js/util/buildscripts, execute:
>
> $ ./build.sh profile="custom"
>
> * The build will be created in public/js/release/custom
>
> * Now replace public/js with public/js/release/custom, and you'll be
> set.
>
> You'll need to clear your browser cache to notice the changes.
>
>
Regards,
Peter Higgins
They will replace the "old book" as soon as they are completed. the
campus wiki exports to about a 650 page PDF now, but still lacks some
explanation. We're working to finalize this before 1.3 ships. Nothing
new has gone into Dojo without full documentation between 1.2 and 1.3,
and we're retroactively trying to fill in any missing blanks.
The build isn't much of a moving target -- it really seldom changes --
it just does a lot and is somewhat complicated when you want to start
doing advanced things. At some point you just "get it", and it is rather
intuitive, but difficult to explain. I'm working on extended text for
all the todocs: at the bottom of the build page.
the jist, and easiest way i've found is to assume you will be doing a
build from the start (you should, no one should use that many files
outside of dev work), and create a physical "layer" in a namespace.
(sibling folder of dojo/ or a registerModulePath'd folder).
dojo/
my/
dijit/
dojox/
util/
and my/layer.js is:
dojo.provide("my.layer");
dojo.require("my.things");
dojo.require("dijit.things");
dojo.require("dojo.dnd.Mover"); // etc etc
then your profile just says "my.layer is dependent on my.layer" -- thus
making an automatic rollup transparent between dev and production. While
you are working, layer.js is just a list of requires sending off
additional requests (no requests will be duplicated, as you mentioned,
they should all be unique, and no-op when a module is requests
previously) ... After you build, layer.js will be the culmination of all
the inline require() calls and their dependencies.
a profile for that (save in util/buildscripts/profiles/my.profile.js):
dependencies = {
stripConsole: "normal",
layers: [
{
name: "../my/layer.js",
resourceName: "my.layer"
dependencies: [
"my.layer"
]
}
],
prefixes: [
[ "my", "../my" ],
[ "dijit", "../dijit" ],
[ "dojox", "../dojox" ]
]
}
Then run a build (util/buildscripts/) You'll need js.jar (Rhino 1.7+)
and shrinksafe.jar, both come shipped with the -src archives available
on http://download.dojotoolkit.org/current-stable/
# basic build:
./build.sh action=release profile=my version=1.2.3
# shrinksafe build:
./build.sh action=release profile=my version=1.2.3 optimize=shrinksafe
# css concatenation?
./build.sh action=release profile=my version=1.2.3 optimize=shrinksafe
cssOptimize=comments.keepLines
# i like keepLines in my css as I sometimes use line-specific hacks that
would be destroyed otherwise
(profile=my assumes profiles/value.profile.js. you can do profileFile
and pass an absolute path if you like instead)
There are a lot of options to work with, and even more goodies within
the build to do very specific things (like omit a whole block of code
for production based on specially crafted comment tags, lazy-requiring
of modules, etc). run ./build.sh without options to see the CLI docs
there about supported command line params.
a folder "release/dojo/" will be made as a sibling of dojo/ ... all
dojo.require()'ing is done relative to dojo.js, so if you point your
page at the 'release' dojo.js, the rest of your modules will be from the
release tree too (layer included)
<!-- simply comment out or use some server-side goodness to determine
dev or production -->
<script src="/js/lib/dojotoolkit/dojo/dojo.js"></script>
<script src="/js/lib/dojotoolkit/release/dojo/dojo/dojo.js"></script>
<!-- this stays the same, regardless -->
<script>dojo.require("my.layer")</script>
Hope this helps. If you have more specific questions, or spot anything
wildly inaccurate in the wiki docs, please don't hesitate to let me
know. Improving Dojo's documentation availability and IA has been my #1
priority since taking this position, and we've made great strides
towards it's completion ... but review is always helpful and necessary.
Regards,
Peter Higgins
Here's the easiest way:
* Create a layer file that contains all your dojo.require() statements:
In public/js/<your custom module>/main.js (I'll call it "custom"):
dojo.provide("custom.main");
(function(){
dojo.require("dijit.form.Form");
dojo.require("dijit.form.Button");
/* etc. */
})();
* In your bootstrap, make sure you reference this layer file:
$view->dojo()->requireModule("custom.main");
* Create a profile: public/js/util/buildscripts/profiles/custom.profile.js
/* ./build.sh profile="custom" */
dependencies = {
action: "release",
version: "1.2.2-custom", /* this can be arbitrary */
releaseName: "custom",
loader: "default",
cssOptimize: "comments.keepLines",
optimize: "shrinksafe",
layerOptimize: "shrinksafe",
copyTests: false,
layers: [
{
name: "../custom/main.js",
layerDependencies: [],
dependencies: [
"custom.main",
]
}
],
prefixes: [
[ "dijit", "../dijit" ],
[ "dojox", "../dojox" ],
[ "custom", "../custom" ]
]
}
* From within public/js/util/buildscripts, execute:
$ ./build.sh profile="custom"
* The build will be created in public/js/release/custom
* Now replace public/js with public/js/release/custom, and you'll be
set.
You'll need to clear your browser cache to notice the changes.
--
Matthew Weier O'Phinney
Software Architect | matthew@zend.com
Zend Framework | http://framework.zend.com/
I'm trying to reduce the number of file requests per page load for my
dojo enhanced ZF app. I created a profile and generated a release, but
I still have 32 or so file requests. Some of them look like duplicates,
as well.
I'm kinda stuck between the documentation on the dojo site (started with
the documentation for an early version, but that was a total waste of
time). I've looked at Matthew's pastebiin demo app (both the download
tarball, and the most recent stuff on github), and also read a bunch of
posts here. Seems like all of this is a fast moving target. None of
the examples match the docs or posts.
Is there recent documentation on the best way to go about this?
--
Drew Bertola
-------------------------------------------------
* PHP/LAMP Consultant, ZCE-1000 *
* *
* Tel: 408-966-6671 *
* *
* current resume: *
* http://drewb.com/blog/about/resume/ *
-------------------------------------------------
A miss the element name in the validation section in addError() method call, here is the good one:
Class SomeForm extends Zend_Form
{
public function __construct($options = null)
{
Your code here
…
}
//override isValid method
public function isValid($data)
{
$valid = true;
//validate your checkbox according your code below, if checkbox is checked, value is set to 1
If ($this->contract->getValue() != 1)
{
$this->contract->addError(‘you must agree our conditions!’);
$valid = false;
}
return parent::isValid($data) && $valid;
}
}
Regards,
Jaime.
De: Jaime Garcia [mailto:jgarcia@vali.com.mx]
Enviado el: Sábado, 27 de Diciembre de 2008 01:43 p.m.
Para: 'Zend Framework MVC'
Asunto: RE: [fw-mvc] Another Zend_Form checkboxes bug ?
Hello John,
I think this behavior is expected in checkboxes due the nature of the element (what is defined as empty o required if you can change checked or unchecked value?). however there is a workaround to do this validation without affect your code outside of your form definition as follows:
Class SomeForm extends Zend_Form
{
public function __construct($options = null)
{
Your code here
…
}
//override isValid method
public function isValid($data)
{
$valid = true;
//validate your checkbox according your code below, if checkbox is checked, value is set to 1
If ($this->contract->getValue() != 1)
{
$this->addError(‘you must agree our conditions!’);
$valid = false;
}
return parent::isValid($data) && $valid;
}
}
I hope this works for your case.
Best Regards,
Jaime Garcia.
De: John Antony Riga [mailto:ja.riga@yahoo.com]
Enviado el: Sábado, 27 de Diciembre de 2008 07:53 a.m.
Para: Zend Framework MVC
Asunto: [fw-mvc] Another Zend_Form checkboxes bug ?
Hello everyone !
I'm having a little problem with checkboxes, I'm using this element :
// ACCEPT CONDITIONS
$this->addElement(
'CheckBox',
'contract',
array(
'label' => 'I accept the terms of service',
'style' =>'margin-left:100px;',
'required' => true,
'checkedValue' => '1',
'validators' => array(array('NotEmpty', true)),
)
);
I need my users to check the checkbox before the can submit the form, but actually it's not the case. Checking the checkbox is not required to validate the form despite what I wrote (require => true) and the form subimts
Is this a bug ? I saw there was a lot of bugs in the checkbox form elements so this might be a new one. Or is this me doing somehting wrong ?
JA.
