unnecessary left joins in findCount()?
I'm running into peformance issues with the findCount() method in the model class.. I am doing a listing of records in a given table, and the record has a few associations for it, however the table that I am querying has 1.8 million records in it, and while I turn off the recursive option in findAll() (which keeps my query time down to 17ms), the findCount() method still LEFT JOINs the 3 other association tables when simply doing a count(*) operation, and this gives me a 16000ms execution time on the findCount() method. Is there a way to tell findCount() that I don't care about the associations, much like I can with findAll()? I suppose I can override it, but this seems like something that should be in the model class, no? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~--~~~~--~~--~--~---
making cake sql-function-aware?
I've been digging around in the archives with searches and I've come across a few people who have this problem, namely dealing with the CakePHP saving routines that aren't DB-keyword-aware.. By this I mean the quoting of NULL and the inability to use functions like PASSWORD() and other database functions. I appreciate that there are PHP-specific solutions to the PASSWORD() problem but I would like my MySQL data to be a bit more portable than that, and not rely on business-logic-level methods to operate on. I would also like to have a more generic solution that is future-proof in case I want to use other MySQL functions in the future (which I can abstract if necessary).. So I'm wondering if anyone out there has come up with solutions for this problem? I know that phpMyAdmin just maintains an array of MySQL keywords and method names so it can intelligently quote.. This is also the approach I took in a previous project.. It would involve patching the value() method in the appropriate DboSource subclass (dbo_mysqli in my case).. The sloppy solution I can thin of is to stick a call in beforeSave() that does an execute() call to retrieve a SELECT call with the password and then stick that in there.. but why use up another query if it can be avoided.. thoughts? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~--~~~~--~~--~--~---
Re: SmartyView+SmartyHelpers
That's pretty slick actually.. I never really thought about extending
the compiler to accept some sort of native array parameter..
I'm a broken record on this, but I would have to extend this to support
nested arrays like:
{helper html->select('Model/field', Array('tabindex' => 1, 'options' =>
Array(0 => 'No', 1 => 'Yes'), 'class' => 'selector' ))}
It's not my fault I like run-time multi-dimensional data structures..
:-) I just find them clean and easy to understand for template
designers..
On Nov 3, 9:29 am, "René" <[EMAIL PROTECTED]> wrote:
> I'm using Smarty for a while now and got around the array issue by this
> compiler helper:
>
> function smarty_compiler_helper($tag_attrs, &$compiler)
> {
> $args = explode('->', $tag_attrs);
> $arg0 = $args[0];
> unset($args[0]);
> $arg1 = implode('->', $args);
> $arg1 = preg_replace('/\$(\w+)/', '$this->_tpl_vars[\'\1\']', $arg1);
> return('echo $this->_tpl_vars[\'' . $arg0 . '\']->' . $arg1 .';');
>
> }With this SmartyPlugin you can use CakePHP helpers like this:
> {helper html->input('Model/field', Array('tabindex' => 1))}
>
> I know this is neither perfect nor clean, but it does the job.
>
> Greetings,
> René
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Cake PHP" group.
To post to this group, send email to cake-php@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/cake-php?hl=en
-~--~~~~--~~--~--~---
Re: getting to the controller from a component's constructor?
Ok well the way I've decided to do this is through a static class variable. That means it only works in PHP5, but that's my environment so it will be good enough for me. In AppController I added: > static $CurrentController and then the constructor has > self::$CurrentController = $this as the last line in it. Now from any object in my app I can access the current page controller by calling AppController::$CurrentController. Works for me.. On Nov 2, 2:07 pm, "sbarre" <[EMAIL PROTECTED]> wrote: > Yeah we talked about this already and this is not a solution for me, as > I said in my first message, my Session class needs access to some > controller parameters during initialization. > > Waiting for the controller's beforeFilter() call is too late for me. > > Thanks for the tip though.. I'll keep thinking.. > > On Nov 1, 5:47 pm, gwoo <[EMAIL PROTECTED]> wrote: > > > use startup(&$controller) method inside your component. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
Re: SmartyView+SmartyHelpers
Here's a Bin of the whole patched SmartyHtmlHelper class if you want to
take a look. I figured we should sort out how it's going to work
before I submit it to CakeForge as a new version to yours.
http://bin.cakephp.org/view/1918458743
On Nov 2, 1:49 pm, "sbarre" <[EMAIL PROTECTED]> wrote:
> On Nov 2, 12:41 pm, "Travis Cline" <[EMAIL PROTECTED]> wrote:
>
>
>
> > How would you approach the $html->css issue, just require rel be
> > passed if you want additional parameters?Just to touch on this:
>
> I've implemented the following code to deal with this issue:
>
> foreach ($funcParams as $param) {
> $paramName = $param->getName();
> if (isset($processedParams[$paramName])) {
> $parameters[$paramName] = $processedParams[$paramName];
> } else {
> if ($param->isDefaultValueAvailable()) {
> $parameters[$paramName] = $param->getDefaultValue();
> } else if (!$param->isOptional()) {
> $smarty->trigger_error("SmartyHtml: Error
> ".$paramName." parameter
> is required for method ".$function_name, E_USER_NOTICE);
> } else {
> $parameters[$paramName] = null;
> }
> }
>
> }So you can see that when we build our final $parameters array that
> we're going to pass to call_user_func_array(), we loop through the
> Reflection-supplied list of all the method's parameters, and first we
> check to see if our smarty plugin supplied a value for this parameters,
> if so, we use it, if not we check if there's a default available, then
> we check if it's ok for the parameter to be missing (triggering an
> error if it's not) and then finally just setting it to null as a last
> resort.
>
> In the end you get a $parameters array that has all of the method's
> parameters in order, and you didn't even need to worry about that in
> your smarty plugin tag.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Cake
PHP" group.
To post to this group, send email to cake-php@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/cake-php
-~--~~~~--~~--~--~---
Re: getting to the controller from a component's constructor?
Yeah we talked about this already and this is not a solution for me, as I said in my first message, my Session class needs access to some controller parameters during initialization. Waiting for the controller's beforeFilter() call is too late for me. Thanks for the tip though.. I'll keep thinking.. On Nov 1, 5:47 pm, gwoo <[EMAIL PROTECTED]> wrote: > use startup(&$controller) method inside your component. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
Re: SmartyView+SmartyHelpers
On Nov 2, 12:41 pm, "Travis Cline" <[EMAIL PROTECTED]> wrote:
>
> How would you approach the $html->css issue, just require rel be
> passed if you want additional parameters?
>
Just to touch on this:
I've implemented the following code to deal with this issue:
foreach ($funcParams as $param) {
$paramName = $param->getName();
if (isset($processedParams[$paramName])) {
$parameters[$paramName] = $processedParams[$paramName];
} else {
if ($param->isDefaultValueAvailable()) {
$parameters[$paramName] = $param->getDefaultValue();
} else if (!$param->isOptional()) {
$smarty->trigger_error("SmartyHtml: Error
".$paramName." parameter
is required for method ".$function_name, E_USER_NOTICE);
} else {
$parameters[$paramName] = null;
}
}
}
So you can see that when we build our final $parameters array that
we're going to pass to call_user_func_array(), we loop through the
Reflection-supplied list of all the method's parameters, and first we
check to see if our smarty plugin supplied a value for this parameters,
if so, we use it, if not we check if there's a default available, then
we check if it's ok for the parameter to be missing (triggering an
error if it's not) and then finally just setting it to null as a last
resort.
In the end you get a $parameters array that has all of the method's
parameters in order, and you didn't even need to worry about that in
your smarty plugin tag.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Cake
PHP" group.
To post to this group, send email to cake-php@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/cake-php
-~--~~~~--~~--~--~---
Re: SmartyView+SmartyHelpers
On Nov 2, 12:41 pm, "Travis Cline" <[EMAIL PROTECTED]> wrote:
> On 11/2/06, sbarre <[EMAIL PROTECTED]> wrote:
>
> > The other idea I had, to avoid doing the collapsed array trick would be
> ...
> > So you could have (for example):
>
> > {html func="input" fieldName="User/username"
> > htmlAttributes_class="formInput" htmlAttributes_size="30"}
> That's a little more verbose than I'd like.
>
> How about just requiring {assign_adv} or the like for more complex situations?
> I think they'll be rare enough requriring them be a bit complex
> wouldn't be terrible.
> i.e.
> {assign_adv var='newarr' value="array('key'=>'value','key'=>'value')"}
> {html func="input" fieldName="User/username" class="formInput"
> size="30" otherparam=$newarr}
Yeah again the problem I have with this approach is that it breaks if
you ever need to do multi-dimensional arrays, and it leaves you with no
feasible solution either.
While I can appreciate that arrays as values in parameter arrays are
rare, why impose this restriction when we can avoid it? I would rather
have one slightly more verbose and flexible tag rather than having to
create potentially multiple {assign_adv} tags prior to my {html} tag,
and also being limited to my array values being scalar only.
To demonstrate, in the testing of my patch to your SmartyHtml Helper I
took this original single-dimension array of params (that came from the
smarty tag):
Array (
[func] => input,
[fieldName] => User/username,
[htmlAttributes_size] => 30,
[htmlAttributes_style_color] => #f90,
[htmlAttributes_style_padding] => 4px,
[htmlAttributes_border_image_x] => 50,
[htmlAttributes_class] => formInput,
[htmlAttributes_border_image_y] => 50,
);
and cleanly converted it to:
Array (
[func] => input
[fieldName] => User/username
[htmlAttributes] => Array (
[size] => 30
[style] => Array (
[color] => #f90
[padding] => 4px
)
[class] => formInput
[border] => Array (
[image] => Array (
[x] => 50
[y] => 50
)
)
)
)
You can see that even the parameters order doesn't matter, and you can
mix them around without risk.
While I can appreciate that it's a bit of an extreme case (and doesn't
actually apply to the input tag), it does demonstrate that the
delimited key name approach does not have nearly as many restrictions
on it as the fake-array assign-in-advance method, and can support any
depth of nested arrays in the parameters list, if required.
I suppose there's no harm in supporting both approaches, although I
ripped out your explode_twice and array-parameter detection code in my
patch of your Helper, since it wasn't needed.. :-)
What do you think?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Cake
PHP" group.
To post to this group, send email to cake-php@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/cake-php
-~--~~~~--~~--~--~---
Re: SmartyView+SmartyHelpers
Ok I've got the patch working on the SmartyHtmlHelper class to use the
underscore-delimited attribute names, and to recursively build arrays
from the attributes list if required.
It works pretty sweet... I'm just trying to sort through how to upload
it to CakeForge now...
On Nov 2, 11:38 am, "sbarre" <[EMAIL PROTECTED]> wrote:
> Ok I see what you're doing, I like it..
>
> The other idea I had, to avoid doing the collapsed array trick would be
> to use the parameter name to identify array elements.. Since all the
> parameters are camelCased we could use dashes or underscores (would
> dots work?) to identify arrayed values...
>
> So you could have (for example):
>
> {html func="input" fieldName="User/username"
> htmlAttributes_class="formInput" htmlAttributes_size="30"}
>
> or something like that. That might be a bit cleaner in the template,
> and I'd lean towards keeping the templates clean and clear and having
> more " figurin' " code in the plugin.. When you parse the parameters
> you can split on the underscore and build the attributes array that
> way.. The reason I'm leaning towards this approach is because the
> fake-array method falls apart if any of the array values need to be
> arrays themselves. I don't know of a helper method where this is the
> case, but it would be nice to future-proof this code a bit. I'm
> starting a big project and I don't doubt that I will end up writing my
> own helpers at some point..
>
> With the underscores method, you can (in theory) keep adding
> underscores and in the plugin code parse it down into a
> multi-dimensional array if you really had to, and it would not require
> changes to the code.
>
> So you could have (this is a bad example but it will do to illustrate
> the point):
>
> {html func="input" fieldName="User/username"
> htmlAttributes_style_padding="5px" htmlAttributes_style_color="#F6F6F9"
> htmlAttributes_size="30"}
>
> In code this would convert to
>
> htmlAttributes => array(
> size => "30"
> style => array(
> padding => "5px",
> color => "#F6F6F9"
> )
> )
>
> or something like that..
>
> Lemme try to patch that into your existing helper (which is excellent
> so far BTW) and we'll see where it goes..
>
> On Nov 2, 5:18 am, "Travis Cline" <[EMAIL PROTECTED]> wrote:
>
> > On 11/2/06, Travis Cline <[EMAIL PROTECTED]> wrote:> Whoops!Whoops again.
>
> > A couple problems/enhancements.
> > If there are parameters after the array parameter that are passed in
> > the order in the actual call is off.
> > Hopefully you get the idea, feel free to up a new version seb.
>
> > It might make sense to seek default values through reflection if we're
> > passing in after that -- looking at $html->css and the like.
>
> > Travis
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Cake
PHP" group.
To post to this group, send email to cake-php@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/cake-php
-~--~~~~--~~--~--~---
Re: SmartyView+SmartyHelpers
Ok I see what you're doing, I like it..
The other idea I had, to avoid doing the collapsed array trick would be
to use the parameter name to identify array elements.. Since all the
parameters are camelCased we could use dashes or underscores (would
dots work?) to identify arrayed values...
So you could have (for example):
{html func="input" fieldName="User/username"
htmlAttributes_class="formInput" htmlAttributes_size="30"}
or something like that. That might be a bit cleaner in the template,
and I'd lean towards keeping the templates clean and clear and having
more " figurin' " code in the plugin.. When you parse the parameters
you can split on the underscore and build the attributes array that
way.. The reason I'm leaning towards this approach is because the
fake-array method falls apart if any of the array values need to be
arrays themselves. I don't know of a helper method where this is the
case, but it would be nice to future-proof this code a bit. I'm
starting a big project and I don't doubt that I will end up writing my
own helpers at some point..
With the underscores method, you can (in theory) keep adding
underscores and in the plugin code parse it down into a
multi-dimensional array if you really had to, and it would not require
changes to the code.
So you could have (this is a bad example but it will do to illustrate
the point):
{html func="input" fieldName="User/username"
htmlAttributes_style_padding="5px" htmlAttributes_style_color="#F6F6F9"
htmlAttributes_size="30"}
In code this would convert to
htmlAttributes => array(
size => "30"
style => array(
padding => "5px",
color => "#F6F6F9"
)
)
or something like that..
Lemme try to patch that into your existing helper (which is excellent
so far BTW) and we'll see where it goes..
On Nov 2, 5:18 am, "Travis Cline" <[EMAIL PROTECTED]> wrote:
> On 11/2/06, Travis Cline <[EMAIL PROTECTED]> wrote:> Whoops!Whoops again.
>
> A couple problems/enhancements.
> If there are parameters after the array parameter that are passed in
> the order in the actual call is off.
> Hopefully you get the idea, feel free to up a new version seb.
>
> It might make sense to seek default values through reflection if we're
> passing in after that -- looking at $html->css and the like.
>
> Travis
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Cake
PHP" group.
To post to this group, send email to cake-php@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/cake-php
-~--~~~~--~~--~--~---
Re: SmartyView+SmartyHelpers
Ok I've done a little bit of digging on PHP5's Reflection API, and I've
figured out the following:
By inspecting a helper's methods - for this example we'll use
$html->input() - we can determine the names of the parameters that a
given method in the helper is expecting.
Based on this information, in our smarty plugin (which takes 2
parameters, the array of params and a ref to the smarty object), we
could do the following:
First, In the smarty template we have a tag like this:
{html func="input" fieldName="User/username"
htmlAttributes="class=>formInput&size=>30"}
In the plugin code that the above tag maps to, we would have:
function smarty_html_wrapper($params,$smarty) {
$function_name = $params['func'];
$parameters = array();
$html = $smarty->view->html; // copy our helper for convenience (this
might be wrong - whatever)
// here we need some code to loop through and "massage" the parameters,
// in order to convert, for example, the htmlAttributes "fake-array"
into a real array,
// and do anything else..
[... blah blah ...]
// parameters all better, moving on...
$htmlReflector = new ReflectionClass($html);
if ($htmlReflector->hasMethod($func)) { // quick sanity check
$funcReflector = $htmlReflector->getMethod($func);
$funcParams = $funcReflector->getParameters(); // returns an array
of parameter names
foreach ($funcParams as $param) {
$parameters[] = $params[$param->getName()];
}
call_user_func_array(array($html,$function_name),$parameters);
} else {
// output some kind of error if the function doesn't exist
}
} // end smarty plugin function
Sorry for the messy markup I'm in a bit of a hurry. I think this, or
maybe something like this (I have not tested this code, I wrote it in
the Google Groups window), would work for creating a single per-helper
plugin (and in fact it would be the same plugin for all the helpers
just with a different name) that doesn't need to know all the details
of all the methods that exist in the helper class itself.. I love
D-R-Y!
Any thoughts on this? Travis? You want to work with me on getting
this going? I'd love to switch back to using Smarty instead of THTML..
Having all that PHP code in my views makes me feel dirty.. :-)
seb
On Nov 1, 5:21 pm, "sbarre" <[EMAIL PROTECTED]> wrote:
> So just to clarify, do you plan on writing smarty plugins for every
> method in every helper?
>
> I went through the same steps that you did, based on my desire to use
> Smarty instead of THTML (mostly because I may have untrusted template
> authors at some point - and also because I've written a custom Smarty
> wrapper that implements namespaces and directory-based fallback and
> better fragment handling and I wanted to use it).
>
> But when I looked through the helpers I realized that writing a plugin
> for each method in each helper was basically a waste of time.
>
> The idea of {html_input field="User/username" class="formInput"
> size="30"} is nice but requires a plugin-per-method for each helper...
> Bleh..
>
> I even toyed around with the idea of a plugin for each helper and
> deriving the method name via a parameter , something like {html
> func="input" field="User/username" ...} but again mapping the plugin
> parameters to the variety of helper methods parameters just didn't seem
> worth the effort unfortunately..
>
> If the helpers all accepted parameters as an array instead it would be
> easy, but they don't, and many of them take a mix of arrays and
> scalars, so there would have to be explicit mapping happening in the
> plugin (correct me if I'm wrong) and that violates the
> Dont-Repeat-Yourself approach a little too much for me..
>
> I would love to find a solution to this (and would even collaborate on
> one if it was worthwhile) and move back to Smarty, especially since I
> am still early in development, but I don't see a reasonable approach.
>
> This gives me an idea actually, Travis, do you need to be backwards
> compatible to PHP4 or are you ok if this solution was PHP-5 only?
>
> I am thinking we could use PHP5's reflection API to map parameters to
> the helper methods, and use PHP's magic methods (__call() etc..) to map
> from the plugin to the helper..
>
> Thoughts?
>
> On Oct 31, 3:59 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> wrote:
>
> > There are several messages floating around without great answers about
> > Smarty integration and I wanted to let other know about some
> > developments.
>
> > A few days back I broke away from development on a homegrown mvc
> > framework and shifted to c
Re: getting to the controller from a component's constructor?
Well, I'm going to try to override the libs/controller/component.php file with a replacement under the app/ folder which is what I did for the Session helpers and components, and if that works, I will post my changes here and you can use them... On Nov 1, 5:27 pm, "Ismael S. Kafeltz" <[EMAIL PROTECTED]> wrote: > I'm trying to solve this same problems two days ago. > Please, someone help us. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
Re: SmartyView+SmartyHelpers
So just to clarify, do you plan on writing smarty plugins for every
method in every helper?
I went through the same steps that you did, based on my desire to use
Smarty instead of THTML (mostly because I may have untrusted template
authors at some point - and also because I've written a custom Smarty
wrapper that implements namespaces and directory-based fallback and
better fragment handling and I wanted to use it).
But when I looked through the helpers I realized that writing a plugin
for each method in each helper was basically a waste of time.
The idea of {html_input field="User/username" class="formInput"
size="30"} is nice but requires a plugin-per-method for each helper...
Bleh..
I even toyed around with the idea of a plugin for each helper and
deriving the method name via a parameter , something like {html
func="input" field="User/username" ...} but again mapping the plugin
parameters to the variety of helper methods parameters just didn't seem
worth the effort unfortunately..
If the helpers all accepted parameters as an array instead it would be
easy, but they don't, and many of them take a mix of arrays and
scalars, so there would have to be explicit mapping happening in the
plugin (correct me if I'm wrong) and that violates the
Dont-Repeat-Yourself approach a little too much for me..
I would love to find a solution to this (and would even collaborate on
one if it was worthwhile) and move back to Smarty, especially since I
am still early in development, but I don't see a reasonable approach.
This gives me an idea actually, Travis, do you need to be backwards
compatible to PHP4 or are you ok if this solution was PHP-5 only?
I am thinking we could use PHP5's reflection API to map parameters to
the helper methods, and use PHP's magic methods (__call() etc..) to map
from the plugin to the helper..
Thoughts?
On Oct 31, 3:59 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> There are several messages floating around without great answers about
> Smarty integration and I wanted to let other know about some
> developments.
>
> A few days back I broke away from development on a homegrown mvc
> framework and shifted to cake (decision was hard but the transition has
> been smooth).
>
> I know all the arguments against using Smarty, no need to reiterate. I
> think it is arguable that with a properly configured Smarty setup (with
> caching) you can rival/beat straight thtml calls.
> But regardless, there are people that will sacrifice a bit of
> performance to be able to use Smarty.
>
> I've updated phpnut's SmartyView example to include:
> - thtml fallback for views (increases the filesize as it overrides
> _getViewFileName -- adding 4 lines) -- I talked to phpnut about
> allowing app/views thtml fallback in core (already does for libs/views)
> but he refused (somewhat understandably, though I think it can be
> accomplished cleanly).
> - I also added the ability to place smarty plugins in
> views/smarty_plugins instead of w/smarty in /vendor.
> - Additionally I coded brief examples of providing smarty function
> wrapping of helper class methods to allow 'native' smarty calls.
>
> This gets around the 'array(' issue in smarty templates, allowing you
> to do something like this:
> {html_input fieldName=User/username class="test" size=30}
> (vs)
> input('User/username',
> array('class'=>'test','size'=30); ?>
> (or even uglier previous smarty method)
>
> Other than expanding the wrappers I have a short todo that will
> increase functionality/usability but I think it's at an acceptable
> state now.
>
> No need for the 'but it's another layer!!!111' comments, we've been
> through them already =)
>
> I personally don't mind much how the vanilla template styles look in
> most cases but this helped soften the fall from moving away from my
> prior work.
>
> See:http://cakeforge.org/snippet/detail.php?type=package&id=30 (SmartyView
> +
> SmartyHelpers)http://cakeforge.org/snippet/detail.php?type=snippet&id=6(Straight
> SmartyView)
> Also, placed a bit of doc here:http://bakery.cakephp.org/articles/view/124
> (made a small edit, went
> back to moderation).
>
> Travis
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Cake
PHP" group.
To post to this group, send email to cake-php@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/cake-php
-~--~~~~--~~--~--~---
getting to the controller from a component's constructor?
I'm just now realizing that a component, at the constructor "moment", does not have access to the controller it is being embedded into.. I'm wondering if this is a security thing, or what the reasoning behind this is? In my case, as I've written on this list before, I've replaced the built-in Cake session handling with my own custom session class, and as a consequence I've had to replace the Session component and the Session helper classes with ones that instance my Session class instead. The problem I am encountering is that my Session class uses controller parameters to initialize itself. As one quick example, I use a hierarchical session storage structure that allows you to set variables at different levels: session > controller >> action >>> section page This means that you can have generic and simple to remember variables like "records_per_page" that co-exist at various levels in the hiearchy making for very efficient view re-use.. There are other places in the constructor that I need to access information about the current URL/parameters/etc , and I'd like to keep it clean and do it through the controller. I am hoping to derive the controller and action names automatically (without parsing the _SERVER variables manually), but this information doesn't seem to be available to me in the constructor of my Session variable. Does anyone know how I can do this without getting into the libs/ folder? Can I safely replace the lib/controller/component.php class with my own in the app/ tree? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
Re: gutting and replacing Session
Once I get it all done and running I will certainly consider submitting and sharing the work I've done. Thanks for the comments.. On Oct 26, 1:13 am, "nate" <[EMAIL PROTECTED]> wrote: > Well, that all sounds about right. All you really need is the > SessionComponent that re-implements the proper methods. > > Any chance you'd want to submit those "extra methods" for consideration > to be included in the core...? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
gutting and replacing Session
So I've been exploring the CakePHP framework for the last week or so, having decided that it was a good starting point for my latest project. I'm familiar with MVC and the "Rails Way" so alot of the internals were straightforward, and so far most of the functionality provided will be more than adequate, however I've run into some serious shortcomings with CakePHP's built-in session handling abilities. I had developed a Session class for a previous project that implements the functionality that I will need for this project, and today's project has been figuring out how I can slot my customized Session class into place without a) breaking things and b) patching any of CakePHP's core files. I've met with some success but I was hoping to get some CakePHP "vets" to chime in on the steps I've taken, to make sure I'm not missing some obscure spots where the old Session could still have its hooks in. My existing class pretty much implemented all the functionality that the CakeSession class provided, so I can easily provide everything that CakePHP expects from a session handler, I just want to make sure nothing is silently broken by what I've done: 1) I set up my Session class and its support classes in the vendor/ folder to keep a clean separation. 2) I patched my Session class to use Cake's ConnectionManager class to do all my database calls. 3) I load my classes in AppController via the vendor() command. 4) I created an app/controllers/components/session.php file to replace the core component, and it implements all the existing functions of the standard one (plus more that I need) using my class instead of CakeSession. 4) I created an app/views/helpers/session.php file to replace the core helper, and (again) it implements all the existing functions plus the new ones I need, using my class instead of CakeSession. (A quick note for anyone creating a helper or a component to interface with a custom class they are using, I used PHP5's __call() magic method to "pass-thru" calls to my Session class from either the helper or the component without having to implement individual proxy methods in both the component and the helper. very handy!) That's what I've done so far. I haven't had to change or replace anything in the core folder and I've been able to do everything in the app folder (which is great - I was very happy to see that this was possible). I did some grep'ing of the sources and I think I've got everything. Can anyone out there see places in CakePHP where sessions are used that I've missed? This is the start of a large project for me so I need to get my foundation solid. Thanks in advance! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
