Wednesday, February 29, 2012

Re: Sending emoticons from iPhone to CakePHP but received blank value

I have get some advice bellow:

MySQL before version 5.5 only supports UTF-8 for the BMP, which includes characters between U+0000 and U+FFFF. 
It cannot store the character at code point U+1F604 or other similar "high characters". MySQL 5.5+ supports utf8mb4utf16 and utf32
which are able to encode these characters. If you're using MySQL 5.5+, use one of these column character sets. 

If you are on MySQL < 5.5, you'll have to use a BLOB column type. That type stores raw bytes without caring about the "characters" in it. 
The downside is that you won't be able to efficiently search or index the text. 

What I have just confirmed now is that emoticons would be stored correctly after changed the field type from varchar to blob in our MySQL 5.1.54

--
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.
 
 
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php

Re: Command history in CakePHP console

I don't know of any, but that might be a fun contribution to add :)

I'd create a lighthouse RFC ticket and post some code to see what people (and the core team) think. It shouldn't be too hard to code, either.

On Wednesday, February 29, 2012 7:33:58 PM UTC-8, Simon Males wrote:
Hello,

Are there any hacks out there to support command history in CakePHP console?

Closest thing I could find is this: https://github.com/sizuhiko/Taste
using Facebook's phpsh.

Though it's not supported by 2.0

--
Simon Males

--
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.
 
 
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php

Re: isAuthorized redirect

It would be easier to debug your code with... you know, code. Can you post your isAuthorized function please?

On Wednesday, February 29, 2012 3:31:34 PM UTC-8, JT wrote:
I'm using isAuthorized to check if the user is an admin or a user. If a user tries to access an admin function I want them to be redirected to the previous page. However when isAuthorized returns false the user is redirected to '/'. How can I change this behaviour?

--
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.
 
 
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php

Command history in CakePHP console

Hello,

Are there any hacks out there to support command history in CakePHP console?

Closest thing I could find is this: https://github.com/sizuhiko/Taste
using Facebook's phpsh.

Though it's not supported by 2.0

--
Simon Males

--
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.


To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php

Re: Using char(36) as a uuid

Just in case, i'm using UUID as primary key for branch office. periodically integrated with database in HO.

On Thu, Mar 1, 2012 at 8:37 AM, Larry E. Masters <phpnut@gmail.com> wrote:
check out all of the plugins at http://cakedc.github.com all of them are using UUID

--
Larry E. Masters


On Wed, Feb 29, 2012 at 8:53 AM, Ighor Martins <ighor.martins@gmail.com> wrote:
Hello,

I was thinking about the use of integer as primary key of the table or use a char(36) as UUID in the entire project,
What I dont like about the integer, is the auto increment number, So I decided to use char(36) 'cause cake automatically fill it with an UUID, but I dont know if this can slow down the search in DB.

So, anyone who used this before, please tell me about that.
Is that right to use this in tables like: Users, Cars, Categories?


Thanks.

--
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.
 
 
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php

--
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.
 
 
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php

--
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.
 
 
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php

Re: Using char(36) as a uuid

check out all of the plugins at http://cakedc.github.com all of them are using UUID

--
Larry E. Masters


On Wed, Feb 29, 2012 at 8:53 AM, Ighor Martins <ighor.martins@gmail.com> wrote:
Hello,

I was thinking about the use of integer as primary key of the table or use a char(36) as UUID in the entire project,
What I dont like about the integer, is the auto increment number, So I decided to use char(36) 'cause cake automatically fill it with an UUID, but I dont know if this can slow down the search in DB.

So, anyone who used this before, please tell me about that.
Is that right to use this in tables like: Users, Cars, Categories?


Thanks.

--
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.
 
 
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php

--
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.
 
 
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php

Re: Using char(36) as a uuid

There is some debate that keys should be meaningful, and I get that - but a UUID is as meaningless as an auto incremented key.

With judicious use of routes, configuration, and other such bits you can utterly hide your IDs from public scrunity if that is what you're worried about... personally I find it much easier to navigate to posts/5 as opposed to posts/aeasd12382nd2jujud3nx3juo3ehu9282 but maybe thats just me.


On Thu, Mar 1, 2012 at 7:26 AM, Miles J <mileswjohnson@gmail.com> wrote:
Whats the reason for disliking auto-incrementing numbers? Its probably the best thing about databases.


On Wednesday, February 29, 2012 6:53:38 AM UTC-8, Ighor Martins wrote:
Hello,

I was thinking about the use of integer as primary key of the table or use a char(36) as UUID in the entire project,
What I dont like about the integer, is the auto increment number, So I decided to use char(36) 'cause cake automatically fill it with an UUID, but I dont know if this can slow down the search in DB.

So, anyone who used this before, please tell me about that.
Is that right to use this in tables like: Users, Cars, Categories?


Thanks.

--
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.
 
 
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php

--
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.
 
 
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php

isAuthorized redirect

I'm using isAuthorized to check if the user is an admin or a user. If a user tries to access an admin function I want them to be redirected to the previous page. However when isAuthorized returns false the user is redirected to '/'. How can I change this behaviour?

--
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.
 
 
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php

Re: Date out of the V2.1 Stable

Release candidates for the most part wont change much from the stable release. The only differences would be bug fixes, so feel free to use it.

On Tuesday, February 28, 2012 8:33:55 AM UTC-8, fitoussi...@gmail.com wrote:
Hi all,

I currently work in a web agency and we wonder, when the stable
version of 2.1 will come out. For now V2.1 R.C
We will work on big projects and big change apparently will be made.

Thank you in advance for your to answer.

--
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.
 
 
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php

Re: Using char(36) as a uuid

Whats the reason for disliking auto-incrementing numbers? Its probably the best thing about databases.

On Wednesday, February 29, 2012 6:53:38 AM UTC-8, Ighor Martins wrote:
Hello,

I was thinking about the use of integer as primary key of the table or use a char(36) as UUID in the entire project,
What I dont like about the integer, is the auto increment number, So I decided to use char(36) 'cause cake automatically fill it with an UUID, but I dont know if this can slow down the search in DB.

So, anyone who used this before, please tell me about that.
Is that right to use this in tables like: Users, Cars, Categories?


Thanks.

--
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.
 
 
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php

Re: Using char(36) as a uuid

it will slow things down and it will store a lot of overhead data (due
to the byte size of those chars compared to integers).
but if speed isnt that big of an issue you are fine.
it gets problematic in the 10000 to 50000 record area
everything from then on you will really feel - especially with some
more joins going on

in one project the boss wanted to use UUIDs everywhere. database size
is more than twice it would be with AIIDs (due to many foreign_id
fields).
I personally favor a mix (only there where necessary)
but that has other downsites or limitations. so in the end it is a
matter of personal preference as long as the data stays in a specific
range.

On 29 Feb., 15:53, Ighor Martins <ighor.mart...@gmail.com> wrote:
> Hello,
>
> I was thinking about the use of integer as primary key of the table or use
> a char(36) as UUID in the entire project,
> What I dont like about the integer, is the auto increment number, So I
> decided to use char(36) 'cause cake automatically fill it with an UUID, but
> I dont know if this can slow down the search in DB.
>
> So, anyone who used this before, please tell me about that.
> Is that right to use this in tables like: Users, Cars, Categories?
>
> Thanks.

--
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.


To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php

Re: Model Array index issue

It was a version issue, php 5.2.4 was installed While 5.2.8 is
required (cakephp 2).


On 29 feb, 16:39, jeremyharris <funeralm...@gmail.com> wrote:
> Are your versions of PHP the same on both setups? Remember that for PHP
> 4.x, you'll need to define $name in your models.
>
>
>
>
>
>
>
> On Tuesday, February 28, 2012 4:49:18 PM UTC-8, Waterschaats wrote:
>
> > I have a weird problem with Models and array's
>
> > I moved a website from a test server to the live server.
> > In the new situate all my code started to complaine about undefined
> > indexes. When debugging an array I see that the array indexes became
> > numbers instead of the Model names!? What can be the problem of that I
> > use the exact same installation of cakephp?
>
> > Below the 2 examples of arrays.
>
> > this is how the array should be.
> > ---------------------------------------------
> > Array
> > (
> >     [0] => Array
> >         (
> >             [MenuItemsTemplates] => Array
> >                 (
> >                     [id] => 152
> >                     [menu_item_id] => 1
> >                 )
>
> >         )
>
> > This is the array on the live server
> > ----------------------------------------------------
> > Array
> > (
> >     [0] => Array
> >         (
> >             [0] => Array
> >                 (
> >                     [id] => 152
> >                     [menu_item_id] => 1
>
> >                 )
>
> >         )
> On Tuesday, February 28, 2012 4:49:18 PM UTC-8, Waterschaats wrote:
>
> > I have a weird problem with Models and array's
>
> > I moved a website from a test server to the live server.
> > In the new situate all my code started to complaine about undefined
> > indexes. When debugging an array I see that the array indexes became
> > numbers instead of the Model names!? What can be the problem of that I
> > use the exact same installation of cakephp?
>
> > Below the 2 examples of arrays.
>
> > this is how the array should be.
> > ---------------------------------------------
> > Array
> > (
> >     [0] => Array
> >         (
> >             [MenuItemsTemplates] => Array
> >                 (
> >                     [id] => 152
> >                     [menu_item_id] => 1
> >                 )
>
> >         )
>
> > This is the array on the live server
> > ----------------------------------------------------
> > Array
> > (
> >     [0] => Array
> >         (
> >             [0] => Array
> >                 (
> >                     [id] => 152
> >                     [menu_item_id] => 1
>
> >                 )
>
> >         )

--
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.


To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php

Send XML as parameter on a POST request

Hi, I'm getting started with Cake and I'm developing a REST web service but have some troubles. I need to send a XML string to the Record action to save that string in the database. The way I'm doing is converting the XML string to hexadecimal in order to include it in my request but I got an HTML output with the following error:

Bad Request

Your browser sent a request that this server could not understand.

Can anybody help me with this issue please? I'm stucked
Thanks in advance.


This is my action:


class TransfersController extends AppController {
public $components = array('RequestHandler');

public function record($rfc = null, $xml = null, $opnum = null) {
if ($this->request->is('post')) {

//Code to manipulate the received data
 
} else {
            $message = 'The request is wrong';
        }
        $this->set('message', $message);
}
}


and this is the request I'm sending:

http://localhost/myapp/transfers/record/RAA04745123QW5/3C3F786D6C2076657273696F6E3D22312E302220656E636F64696E673D227574662D38223F3E0A3C736F6170656E763A456E76656C6F706520786D6C6E733A736F6170656E763D22687474703A2F2F736368656D61732E786D6C736F61702E6F72672F736F61702F656E76656C6F70652F2220786D6C6E733A6F786D6C3D22687474703A2F2F7777772E76656E74616E696C6C61756E6963612E676F622E6D782F636F76652F77732F6F786D6C2F223E3C736F6170656E763A4865616465723E3C777373653A536563757269747920786D6C6E733A777373653D22687474703A2F2F646F63732E6F617369732D6F70656E2E6F72672F7773732F323030342F30312F6F617369732D3230303430312D7773732D777373656375726974792D7365636578742D312E302E7873642220736F6170656E763A6D757374556E6465727374616E643D2231223E3C777373653A557365726E616D65546F6B656E3E093C777373653A557365726E616D653E5241413034313031344A41323C2F777373653A557365726E616D653E3C777373653A50617373776F726420547970653D22687474703A2F2F646F63732E6F617369732D6F70656E2E6F72672F7773732F323030342F30312F6F617369732D3230303430312D7773732D757365726E616D652D746F6B656E2D70726F66696C652D312E302350617373776F726454657874223E614571526C587955784F5737754959487858314B477A6B594449394638504B614C55745A716F62484D745944414872416142364C554F46376D4F675854486A563C2F777373653A50617373776F72643E3C2F777373653A557365726E616D65546F6B656E3E3C2F777373653A53656375726974793E3C2F736F6170656E763A4865616465723E3C736F6170656E763A426F64793E3C6F786D6C3A736F6C69636974617252656369626972436F7665536572766963696F3E3C6F786D6C3A636F6D70726F62616E7465733E3C6F786D6C3A7469706F4964656E746966696361646F723E303C2F6F786D6C3A7469706F4964656E746966696361646F723E3C6F786D6C3A6964656E74696669636163696F6E3E35322D303734313736323C2F6F786D6C3A6964656E74696669636163696F6E3E3C6F786D6C3A666563686145787065646963696F6E3E323031312D30332D31383C2F6F786D6C3A666563686145787065646963696F6E3E3C6F786D6C3A636572746966696361646F4F726967656E3E303C2F6F786D6C3A636572746966696361646F4F726967656E3E3C6F786D6C3A726663436F6E73756C74613E5241413034313031344A41323C2F6F786D6C3A726663436F6E73756C74613E3C6F786D6C3A7375626469766973696F6E3E303C2F6F786D6C3A7375626469766973696F6E3E3C6F786D6C3A7469706F466967757261416475616E616C3E313C2F6F786D6C3A7469706F466967757261416475616E616C3E3C6F786D6C3A637572703E5A5A414D3537303130314D5A53444C5230353C2F6F786D6C3A637572703E3C6F786D6C3A636F7272656F456C656374726F6E69636F3E6C73657272616E6F40616475616E61736F66742E636F6D2E6D783C2F6F786D6C3A636F7272656F456C656374726F6E69636F3E3C6F786D6C3A6669726D61456C656374726F6E6963613E3C6F786D6C3A636572746966696361646F3E3330383230343443333038323033333441303033303230313032303231343330333033303330333133303330333033303330333033313330333433303337333333363333333633303044303630393241383634383836463730443031303130353035303033303832303133363331333833303336303630333535303430333043324634313245343332453230363436353643323035333635373237363639363336393646323036343635323034313634364436393645363937333734373236313633363943334233364532303534373236393632373537343631373236393631333132463330324430363033353530343041304332363533363537323736363936333639364632303634363532303431363436443639364536393733373437323631363336394333423336453230353437323639363237353734363137323639363133313146333031443036303932413836343838364637304430313039303131363130363136333646363437333430373336313734324536373646363232453644373833313236333032343036303335353034303930433144343137363245323034383639363436313643363736463230333733373243323034333646364332453230343737353635373237323635373236463331304533303043303630333535303431313043303533303336333333303330333130423330303930363033353530343036313330323444353833313139333031373036303335353034303830433130343436393733373437323639373436463230343636353634363537323631364333313133333031313036303335353034303730433041343337353631373536383734363536443646363333313333333033313036303932413836343838364637304430313039303230433234353236353733373036463645373336313632364336353341323034363635373236453631364536343646323034443631373237344333414436453635374132303433364637333733333031453137304433313331333033373332333633323330333333383334333935413137304433313333333133303332333333323330333333383334333935413330383142413331323033303145303630333535303430333133313735323446344434313230343134373435344534333439343132303431343435353431344534313443323035333433333132303330314530363033353530343239313331373532344634443431323034313437343534453433343934313230343134343535343134453431344332303533343333313230333031453036303335353034304131333137353234463444343132303431343734353445343334393431323034313434353534313445343134433230353334333331304233303039303630333535303430363133303234443538333132353330323330363033353530343244313331433532343134313330333433313330333133343441343133323230324632303530343134373539333733303330333333323339353135313338333131453330314330363033353530343035313331353230324632303530343134373539333733303330333333323339344434333438353235343443333033343330383139463330304430363039324138363438383646373044303130313031303530303033383138443030333038313839303238313831303043383444353236463032363839443730453032304635463538373743363744423834313233353031323641383530424543364344343634434642443443323231384138374533353335434146463833413432433439334135363936394431323036454545314336423137413243324138443134313435354136373246384338414231433745363439323235384139304434313830313144463935414230463436303131303443383141413242304130344333314135374233313031444445324434354337383043434446363744343234324239353139353736304342303330374535444135323338424630414134424533434641463032353833313630323344303230333031303030314133344633303444333030433036303335353144313330313031464630343032333030303330304230363033353531443046303430343033303230334438333031313036303936303836343830313836463834323031303130343034303330323035413033303144303630333535314432353034313633303134303630383242303630313035303530373033303430363038324230363031303530353037303330323330304430363039324138363438383646373044303130313035303530303033383230313031303042464542453633314141354239344433373443394332383844323231444631454237363833423144394235463930363331453142443230413445413936463342433032344437343836354134434234413342393143374646373237393044373035334341303331313430374531364345424431334534453743383539333543303833413141454241374243363736394143353134423934373243314633343438434343454242443634424244344630334446443344463530374632334133414339383437344142304145363832394545344445413531433138454242333135413533334134463442463039333245453435343537463634363242323230364130364243314631374336334439374435324646334342424142414131434136394435374443434642354130433236413046363232414236443041343739384345453945333545353838363746413630453832343541453845433534393941353142393935314244433041304438333841314342463644454138353944334531393632363636393444363139434238434245324643423235363030423330454437344333344439443538383141374437343642303245374645333744413046443433374432423733374144334332373138353738413042383633453931383245353933443835394632353732384243373746434432304134363442364546313138373C2F6F786D6C3A636572746966696361646F3E3C6F786D6C3A636164656E614F726967696E616C3E7C307C35322D303734313736327C3033313831312D32317C307C307C323031312D30332D31387C307C317C5A5A414D3537303130314D5A53444C5230357C5241413034313031344A41327C307C35322D303734313736327C424F574C455320464C55494449435320434F52507C444F4242494E20524F41447C363632357C434F4C554D4249417C4D4152594C414E447C5553417C32313034357C317C45474D303330333235374A317C454E54524144412047524F5550204445204D455849434F20532E20444520522E4C2E20444520432E562E7C4341525245544552412020465245534E494C4C4F20504C415445524F53204B4D2E327C532F4E7C50415251554520494E445553545249414C20465245534E494C4C4F7C465245534E494C4C4F7C5A41434154454341537C4D45587C39393035397C5455424F532052494749444F53204445204D4154455249415320504C415354494341537C367C33343530302E3030307C322E39307C3130303230392E33347C383238362E393030307C4DC3814E4755455241532044452043415543484F20434F4E205355532041434345534F52494F537C367C333030302E3030307C382E34397C32353436362E38317C323130362E303030307C5455424F532052494749444F537C367C313530302E3030307C312E38367C323739352E31387C3233312E313530307C3C2F6F786D6C3A636164656E614F726967696E616C3E3C6F786D6C3A6669726D613E414538364343333835433837334246423334343430323130314533433444353642314133464331304442303441384539444644394345433731364232314539344137323433423031373930453231433935303237453946423736334539394246414433334144323041384638333138353339393039384641443244354341383937413333373332444632393530303839434346444234354546373533334442373741323741343241433630353844414533364333363342393036464345324630414538304335443935393439453133453732353031393839353542443944304130453546444441413346324438393943393945303531313945323443443437373C2F6F786D6C3A6669726D613E3C2F6F786D6C3A6669726D61456C656374726F6E6963613E3C6F786D6C3A6E756D65726F466163747572614F726967696E616C3E3033313831312D32313C2F6F786D6C3A6E756D65726F466163747572614F726967696E616C3E3C6F786D6C3A656D69736F723E3C6F786D6C3A7469706F4964656E746966696361646F723E303C2F6F786D6C3A7469706F4964656E746966696361646F723E3C6F786D6C3A6964656E74696669636163696F6E3E35322D303734313736323C2F6F786D6C3A6964656E74696669636163696F6E3E3C6F786D6C3A6E6F6D6272653E424F574C455320464C55494449435320434F52503C2F6F786D6C3A6E6F6D6272653E3C6F786D6C3A646F6D6963696C696F3E3C6F786D6C3A63616C6C653E444F4242494E20524F41443C2F6F786D6C3A63616C6C653E3C6F786D6C3A6E756D65726F4578746572696F723E363632353C2F6F786D6C3A6E756D65726F4578746572696F723E3C6F786D6C3A6C6F63616C696461643E434F4C554D4249413C2F6F786D6C3A6C6F63616C696461643E3C6F786D6C3A656E7469646164466564657261746976613E4D4152594C414E443C2F6F786D6C3A656E7469646164466564657261746976613E3C6F786D6C3A706169733E5553413C2F6F786D6C3A706169733E3C6F786D6C3A636F646967506F7374616C3E32313034353C2F6F786D6C3A636F646967506F7374616C3E3C2F6F786D6C3A646F6D6963696C696F3E3C2F6F786D6C3A656D69736F723E3C6F786D6C3A64657374696E61746172696F3E3C6F786D6C3A7469706F4964656E746966696361646F723E313C2F6F786D6C3A7469706F4964656E746966696361646F723E3C6F786D6C3A6964656E74696669636163696F6E3E45474D303330333235374A313C2F6F786D6C3A6964656E74696669636163696F6E3E3C6F786D6C3A6E6F6D6272653E454E54524144412047524F5550204445204D455849434F20532E20444520522E4C2E20444520432E562E3C2F6F786D6C3A6E6F6D6272653E3C6F786D6C3A646F6D6963696C696F3E3C6F786D6C3A63616C6C653E4341525245544552412020465245534E494C4C4F20504C415445524F53204B4D2E323C2F6F786D6C3A63616C6C653E3C6F786D6C3A6E756D65726F4578746572696F723E532F4E3C2F6F786D6C3A6E756D65726F4578746572696F723E3C6F786D6C3A636F6C6F6E69613E50415251554520494E445553545249414C20465245534E494C4C4F3C2F6F786D6C3A636F6C6F6E69613E3C6F786D6C3A6C6F63616C696461643E465245534E494C4C4F3C2F6F786D6C3A6C6F63616C696461643E3C6F786D6C3A656E7469646164466564657261746976613E5A41434154454341533C2F6F786D6C3A656E7469646164466564657261746976613E3C6F786D6C3A706169733E4D45583C2F6F786D6C3A706169733E3C6F786D6C3A636F646967506F7374616C3E39393035393C2F6F786D6C3A636F646967506F7374616C3E3C2F6F786D6C3A646F6D6963696C696F3E3C2F6F786D6C3A64657374696E61746172696F3E3C6F786D6C3A6D657263616E636961733E3C6F786D6C3A6465736372697063696F6E47656E65726963613E5455424F532052494749444F53204445204D4154455249415320504C415354494341533C2F6F786D6C3A6465736372697063696F6E47656E65726963613E3C6F786D6C3A636C617665556E696461643E363C2F6F786D6C3A636C617665556E696461643E3C6F786D6C3A63616E74696461643E33343530302E3030303C2F6F786D6C3A63616E74696461643E3C6F786D6C3A76616C6F72556E69746172696F3E322E39303C2F6F786D6C3A76616C6F72556E69746172696F3E3C6F786D6C3A76616C6F72546F74616C3E3130303230392E33343C2F6F786D6C3A76616C6F72546F74616C3E3C6F786D6C3A76616C6F72446F6C617265733E383238362E393030303C2F6F786D6C3A76616C6F72446F6C617265733E3C2F6F786D6C3A6D657263616E636961733E3C6F786D6C3A6D657263616E636961733E3C6F786D6C3A6465736372697063696F6E47656E65726963613E4DC3814E4755455241532044452043415543484F20434F4E205355532041434345534F52494F533C2F6F786D6C3A6465736372697063696F6E47656E65726963613E3C6F786D6C3A636C617665556E696461643E363C2F6F786D6C3A636C617665556E696461643E3C6F786D6C3A63616E74696461643E333030302E3030303C2F6F786D6C3A63616E74696461643E3C6F786D6C3A76616C6F72556E69746172696F3E382E34393C2F6F786D6C3A76616C6F72556E69746172696F3E3C6F786D6C3A76616C6F72546F74616C3E32353436362E38313C2F6F786D6C3A76616C6F72546F74616C3E3C6F786D6C3A76616C6F72446F6C617265733E323130362E303030303C2F6F786D6C3A76616C6F72446F6C617265733E3C2F6F786D6C3A6D657263616E636961733E3C6F786D6C3A6D657263616E636961733E3C6F786D6C3A6465736372697063696F6E47656E65726963613E5455424F532052494749444F533C2F6F786D6C3A6465736372697063696F6E47656E65726963613E3C6F786D6C3A636C617665556E696461643E363C2F6F786D6C3A636C617665556E696461643E3C6F786D6C3A63616E74696461643E313530302E3030303C2F6F786D6C3A63616E74696461643E3C6F786D6C3A76616C6F72556E69746172696F3E312E38363C2F6F786D6C3A76616C6F72556E69746172696F3E3C6F786D6C3A76616C6F72546F74616C3E323739352E31383C2F6F786D6C3A76616C6F72546F74616C3E3C6F786D6C3A76616C6F72446F6C617265733E3233312E313530303C2F6F786D6C3A76616C6F72446F6C617265733E3C2F6F786D6C3A6D657263616E636961733E3C2F6F786D6C3A636F6D70726F62616E7465733E3C2F6F786D6C3A736F6C69636974617252656369626972436F7665536572766963696F3E3C2F736F6170656E763A426F64793E3C2F736F6170656E763A456E76656C6F70653E0A/15/.xml

--
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.
 
 
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php

Re: Media Plugin - Getting Started

Hi to all, 
I'm trying to handle with video files, but with no luck. 
I'm working on this stuff 
var $validate = array(
'file' => array(
'resource'   => array('rule' => 'checkResource'),
'access'     => array('rule' => 'checkAccess'),
'location'   => array('rule' => array('checkLocation', array(
MEDIA_TRANSFER, '/tmp/'
))),
'extension'  => array('rule' => array('checkExtension', false, array(
'jpg', 'jpeg', 'png', 'tif', 'tiff', 'gif', 'pdf', 'tmp','avi','mpeg'
))),
'mimeType'   => array('rule' => array('checkMimeType', false, array(
'image/jpeg', 'image/png', 'image/tiff', 'image/gif', 'application/pdf','video/x-msvideo','video/vnd.mpegurl','video/mpeg'
)))));


Il giorno mercoledì 7 luglio 2010 04:26:16 UTC+2, dbme ha scritto:
Awesome! So what is your directory structure (step 3)?

Is it

app/webroot/media/static/
app/webroot/media/filter/
app/transfer/

OR

app/webroot/media/static/
app/webroot/media/filter/
app/webroot/media/transfer/

Also, did the styles still get served properly after step 5
(protecting the transfer directory)?

I would love to see how you made it work! Would you mind posting an
example or emailing me the relevant code?
If I can get it working I think it would be great to add this as a
full-on tutorial in the wiki.

Thank you!!


On Jul 6, 6:11 pm, randy <ran...@gmail.com> wrote:
> So glad to see someone else is taking a crack at this...
>
> Thanks to your post i was able to make a bit of headway...when i set
> this up the first time I had troubles with getting things right in my
> bootstrap.php file. However, i had a fairly easy time with other parts
> of this, namely the actual file-upload and metadata fields.
>
> I just set this up again using your instructions for bootstrap.php,
> and with just a few more adjustments I have it uploading files to the
> transfer directory and spitting out copies of the original, in
> different sizes.
>
> There are just two more things that I want to get working...I'd like
> to use the Media Helper to pull in my uploaded images, and, most
> importantly, I'd like to get the file-renaming functionality working
> so that users don't overwrite each others files. This also makes it
> tough to guess filenames if people go fishing for the uploaded images.
>
> I am running this on a cake 1.3 setup in case anyone was wondering.
>
> On Jul 5, 1:30 pm, dbme <boston.dus...@gmail.com> wrote:
>
> > I'm just getting started with CakePHP and also David Persson's Media
> > plugin (http://github.com/davidpersson/media). I've got my app working
> > but I'm having a difficult time getting the Media plugin working. I
> > figured I'd start this thread so I could A.) get it working and B.)
> > create a reference for beginners like me.
>
> > Here's what I've done so far (following the README and Configuration
> > wiki -http://wiki.github.com/davidpersson/media/configuration). Steps
> > marked with a * didn't go as documented :(
>
> > 1. Download and extract the files to /path/to/your/app/plugins/media
> > 2. Include the Media plugin config file in the /path/to/your/app/
> > config/bootstrap.php
>
> >         define ( 'MEDIA_TRANSFER', APP . 'transfer' . DS);
> >         define ( 'MEDIA_TRANSFER_URL', false);
> >         require APP . 'plugins/media/config/core.php';
>
> > * 3. Create the directory structure using the console
>
> > cd  /path/to/your/app/
> > ../cake/console/cake media init
>
> > The Configuration wiki says that there should be a static, filter, and
> > transfer directory under the webroot/media/ directory but the command
> > above will put the transfer directory under the app directory. Not
> > sure if this is how it should be or if I did something wrong.
>
> > * 4. Copy/move/collect the media into the new location
>
> > ../cake/console/cake media collect
>
> > But this results in a bunch of errors :(
>
> > --------------------------------------------------------------------------- -----
> > Media Shell
> > --------------------------------------------------------------------------- -----
> > PHP Warning:  Invalid argument supplied for foreach() in /path/to/your/
> > app/plugins/media/vendors/shells/tasks/collect.php on line 119
>
> > Warning: Invalid argument supplied for foreach() in /path/to/your/app/
> > plugins/media/vendors/shells/tasks/collect.php on line 119
> > PHP Notice:  Undefined variable: pluginVendorPaths in /var/www/
> > portfolio/app/plugins/media/vendors/shells/tasks/collect.php on line
> > 130
>
> > Notice: Undefined variable: pluginVendorPaths in /path/to/your/app/
> > plugins/media/vendors/shells/tasks/collect.php on line 130
> > PHP Warning:  array_merge(): Argument #1 is not an array in /path/to/
> > your/app/plugins/media/vendors/shells/tasks/collect.php on line 130
>
> > Warning: array_merge(): Argument #1 is not an array in /path/to/your/
> > app/plugins/media/vendors/shells/tasks/collect.php on line 130
> > PHP Warning:  Invalid argument supplied for foreach() in /path/to/your/
> > app/plugins/media/vendors/shells/tasks/collect.php on line 132
>
> > Warning: Invalid argument supplied for foreach() in /path/to/your/app/
> > plugins/media/vendors/shells/tasks/collect.php on line 132
> > Would you like to add another path?
>
> > So I'm assuming maybe I've done something wrong. I will press on and
> > instead just move the files manually:
>
> > mv webroot/js/* webroot/media/static/js/
> > mv webroot/css/* webroot/media/static/css/
> > mv webroot/img/* webroot/media/static/img/
> > mv webroot/vendors/js/* webroot/media/static/js/
> > mv webroot/vendors/css/* webroot/media/static/css/
> > mv webroot/vendors/img/* webroot/media/static/img/
>
> > That works, minus the vendors directory (because I dont have one).
> > At this point the app is no longer styled. e.g. the stylesheet is not
> > in the proper path and afaik there isn't anything telling the app
> > where to find it. :-/
>
> > Next step.
>
> > * 5. Protect the transfer directory
>
> > ../cake/console/cake media protect
>
> > Doesn't work. I just get the message: The content of the transfer
> > directory is not served. Guess I'll create this one manually as well.
>
> > nano transfer/.htaccess
>
> > Order deny,allow
> > Deny from all
>
> > Save and exit.
>
> > 6. Give up.
>
> > Actually I pressed on but there really isn't any thorough
> > documentation after this point.
>
> > Any help would be appreciated. I'd love to put together some
> > documentation that would help other n00bs like me get this thing set
> > up.

--
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.
 
 
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php

Re: Media PLugin

What about setting an empty hidden field in the view, like

echo $this->Form->hidden('Model.file', array('value' => ''));

I'd probably be more prone to just copy and paste the Coupler to my own behaviors and modify it, or create a new small behavior that is just dedicated to this task.

On Wednesday, February 29, 2012 7:49:01 AM UTC-8, keith...@classoutfit.com wrote:
I tried it earlier by adding the following to the end of the beforeSave() in our Users model:

if (!isset($this->data['User']['file'])) { $this->data['User']['file'] = null; }

But when I tested it I discovered that the beforeSave() in the Media Coupler was firing before the beforeSave() in our Users model, so it was too late to add the empty 'file' key to the array as the 'User' had already been unset by the Coupler. I've therefore had to roll the change back and go back to the drawing board for now.

On 29 Feb 2012, at 15:21, jeremyharris wrote:

I probably didn't take your reply the right way. Hopefully I wasn't too harsh myself.

Anyway, hopefully you'll get a response from David soon. Did you ever get to try out passing an empty 'file' key in the form (i.e., a hidden field)? That way, the key would exist and the Coupler wouldn't unset the data. I don't think this is a very elegant solution either, but I was curious if you tried it out.

On Tuesday, February 28, 2012 8:41:39 PM UTC-8, Jeremy Burns wrote:
Gosh my reply sounded harsh on you Jeremy - that wasn't my intention. We've commented out the line that unsets the data and it *all seems fine*, which also feels dirty. The user records are saving correctly, we can subsequently add images to user records and all other dedicated image tables that use the coupler are functioning too. I did reach out to David yesterday, hoping to learn more from him so that we can implement this properly and will report back.

Jeremy Burns

On 28 Feb 2012, at 21:15:25, jeremyharris wrote:

I didn't say I agreed with how it worked, I was just explaining what I think the author's intended use case was. The question was if you were missing a setting or doing anything wrong. You weren't, so I just threw out some ideas based on how the Coupler works. Feel free to take it up with the author or create a Coupler that works for you.

I'm glad that an empty image doesn't create garbage data, that thought was based off of what the Coupler does down the road (check the file and populate dirname and basename).

On Tuesday, February 28, 2012 12:06:23 PM UTC-8, Jeremy Burns wrote:
I understand what you are saying but I don't think it's the full answer. It's a perfectly valid use case to have a table that has an optional image in it without the need to have a separate join table. The absence of the image doesn't create any garbage data; the user row is still valid. A bio snap for a user is good example. For the plugin to simply clear the whole data array because the optional image fields aren't populated is nuts. If the fields are empty simply return true and let the main model get on with its work.

Jeremy Burns

On 28 Feb 2012, at 15:45:29, jeremyharris wrote:

It should only unset the data if you are creating the User and it's missing the 'file' key. If you are updating, you shouldn't *need* the 'file' key.

That said, you can probably get away with passing an empty (or a path to a default image) file key when you are creating the User using a hidden field. This should allow the coupler to continue with the save. This may save some empty garbage data that is probably unwanted.

The other solution would be to detach the Coupler behavior at runtime when you don't want it to "force" you to have an image.

The whole point of the Coupler is to tightly couple the physical image to the record, so if the image doesn't exist neither should the record. I tend to create a separate table for attachments for this very reason. A user should be allowed to exist without an image.

On Tuesday, February 28, 2012 5:42:11 AM UTC-8, Jeremy Burns wrote:
I'm using David Persson's media plugin. I have a users table that
contains the fields necessary to link to an image file, but a user
does not have to have an image. When I include the Media.Coupler
behaviour in the User model User->create always fails on User->save
when the user does not have an image because of the beforeSave in
coupler.php:

        function beforeSave(&$Model) {
                if (!$Model->exists()) {
                        if (!isset($Model->data[$Model->alias]['file'])) {
                                 unset($Model->data[$Model->alias]);  <<<--- clears down my User
data
                                return true;
                        }
                } else {

This is unsetting the User data because the file key is missing. If I
comment out the unset my User->save is successful. The Media.Coupler
is working perfectly well for another table that hasMany images in an
associated table.

Is there a setting I need to configure or am I doing something else
wrong?

--
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.
 
 
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php


On Tuesday, February 28, 2012 12:06:23 PM UTC-8, Jeremy Burns wrote:
I understand what you are saying but I don't think it's the full answer. It's a perfectly valid use case to have a table that has an optional image in it without the need to have a separate join table. The absence of the image doesn't create any garbage data; the user row is still valid. A bio snap for a user is good example. For the plugin to simply clear the whole data array because the optional image fields aren't populated is nuts. If the fields are empty simply return true and let the main model get on with its work.

Jeremy Burns

On 28 Feb 2012, at 15:45:29, jeremyharris wrote:

It should only unset the data if you are creating the User and it's missing the 'file' key. If you are updating, you shouldn't *need* the 'file' key.

That said, you can probably get away with passing an empty (or a path to a default image) file key when you are creating the User using a hidden field. This should allow the coupler to continue with the save. This may save some empty garbage data that is probably unwanted.

The other solution would be to detach the Coupler behavior at runtime when you don't want it to "force" you to have an image.

The whole point of the Coupler is to tightly couple the physical image to the record, so if the image doesn't exist neither should the record. I tend to create a separate table for attachments for this very reason. A user should be allowed to exist without an image.

On Tuesday, February 28, 2012 5:42:11 AM UTC-8, Jeremy Burns wrote:
I'm using David Persson's media plugin. I have a users table that
contains the fields necessary to link to an image file, but a user
does not have to have an image. When I include the Media.Coupler
behaviour in the User model User->create always fails on User->save
when the user does not have an image because of the beforeSave in
coupler.php:

        function beforeSave(&$Model) {
                if (!$Model->exists()) {
                        if (!isset($Model->data[$Model->alias]['file'])) {
                                 unset($Model->data[$Model->alias]);  <<<--- clears down my User
data
                                return true;
                        }
                } else {

This is unsetting the User data because the file key is missing. If I
comment out the unset my User->save is successful. The Media.Coupler
is working perfectly well for another table that hasMany images in an
associated table.

Is there a setting I need to configure or am I doing something else
wrong?

--
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.
 
 
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php


--
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.
 
 
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php


On Tuesday, February 28, 2012 8:41:39 PM UTC-8, Jeremy Burns wrote:
Gosh my reply sounded harsh on you Jeremy - that wasn't my intention. We've commented out the line that unsets the data and it *all seems fine*, which also feels dirty. The user records are saving correctly, we can subsequently add images to user records and all other dedicated image tables that use the coupler are functioning too. I did reach out to David yesterday, hoping to learn more from him so that we can implement this properly and will report back.

Jeremy Burns

On 28 Feb 2012, at 21:15:25, jeremyharris wrote:

I didn't say I agreed with how it worked, I was just explaining what I think the author's intended use case was. The question was if you were missing a setting or doing anything wrong. You weren't, so I just threw out some ideas based on how the Coupler works. Feel free to take it up with the author or create a Coupler that works for you.

I'm glad that an empty image doesn't create garbage data, that thought was based off of what the Coupler does down the road (check the file and populate dirname and basename).

On Tuesday, February 28, 2012 12:06:23 PM UTC-8, Jeremy Burns wrote:
I understand what you are saying but I don't think it's the full answer. It's a perfectly valid use case to have a table that has an optional image in it without the need to have a separate join table. The absence of the image doesn't create any garbage data; the user row is still valid. A bio snap for a user is good example. For the plugin to simply clear the whole data array because the optional image fields aren't populated is nuts. If the fields are empty simply return true and let the main model get on with its work.

Jeremy Burns

On 28 Feb 2012, at 15:45:29, jeremyharris wrote:

It should only unset the data if you are creating the User and it's missing the 'file' key. If you are updating, you shouldn't *need* the 'file' key.

That said, you can probably get away with passing an empty (or a path to a default image) file key when you are creating the User using a hidden field. This should allow the coupler to continue with the save. This may save some empty garbage data that is probably unwanted.

The other solution would be to detach the Coupler behavior at runtime when you don't want it to "force" you to have an image.

The whole point of the Coupler is to tightly couple the physical image to the record, so if the image doesn't exist neither should the record. I tend to create a separate table for attachments for this very reason. A user should be allowed to exist without an image.

On Tuesday, February 28, 2012 5:42:11 AM UTC-8, Jeremy Burns wrote:
I'm using David Persson's media plugin. I have a users table that
contains the fields necessary to link to an image file, but a user
does not have to have an image. When I include the Media.Coupler
behaviour in the User model User->create always fails on User->save
when the user does not have an image because of the beforeSave in
coupler.php:

        function beforeSave(&$Model) {
                if (!$Model->exists()) {
                        if (!isset($Model->data[$Model->alias]['file'])) {
                                 unset($Model->data[$Model->alias]);  <<<--- clears down my User
data
                                return true;
                        }
                } else {

This is unsetting the User data because the file key is missing. If I
comment out the unset my User->save is successful. The Media.Coupler
is working perfectly well for another table that hasMany images in an
associated table.

Is there a setting I need to configure or am I doing something else
wrong?

--
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.
 
 
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php


On Tuesday, February 28, 2012 12:06:23 PM UTC-8, Jeremy Burns wrote:
I understand what you are saying but I don't think it's the full answer. It's a perfectly valid use case to have a table that has an optional image in it without the need to have a separate join table. The absence of the image doesn't create any garbage data; the user row is still valid. A bio snap for a user is good example. For the plugin to simply clear the whole data array because the optional image fields aren't populated is nuts. If the fields are empty simply return true and let the main model get on with its work.

Jeremy Burns

On 28 Feb 2012, at 15:45:29, jeremyharris wrote:

It should only unset the data if you are creating the User and it's missing the 'file' key. If you are updating, you shouldn't *need* the 'file' key.

That said, you can probably get away with passing an empty (or a path to a default image) file key when you are creating the User using a hidden field. This should allow the coupler to continue with the save. This may save some empty garbage data that is probably unwanted.

The other solution would be to detach the Coupler behavior at runtime when you don't want it to "force" you to have an image.

The whole point of the Coupler is to tightly couple the physical image to the record, so if the image doesn't exist neither should the record. I tend to create a separate table for attachments for this very reason. A user should be allowed to exist without an image.

On Tuesday, February 28, 2012 5:42:11 AM UTC-8, Jeremy Burns wrote:
I'm using David Persson's media plugin. I have a users table that
contains the fields necessary to link to an image file, but a user
does not have to have an image. When I include the Media.Coupler
behaviour in the User model User->create always fails on User->save
when the user does not have an image because of the beforeSave in
coupler.php:

        function beforeSave(&$Model) {
                if (!$Model->exists()) {
                        if (!isset($Model->data[$Model->alias]['file'])) {
                                 unset($Model->data[$Model->alias]);  <<<--- clears down my User
data
                                return true;
                        }
                } else {

This is unsetting the User data because the file key is missing. If I
comment out the unset my User->save is successful. The Media.Coupler
is working perfectly well for another table that hasMany images in an
associated table.

Is there a setting I need to configure or am I doing something else
wrong?

--
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.
 
 
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php


--
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.
 
 
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php


--
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.
 
 
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php

--
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.
 
 
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php

Re: Media PLugin

I tried it earlier by adding the following to the end of the beforeSave() in our Users model:

if (!isset($this->data['User']['file'])) { $this->data['User']['file'] = null; }

But when I tested it I discovered that the beforeSave() in the Media Coupler was firing before the beforeSave() in our Users model, so it was too late to add the empty 'file' key to the array as the 'User' had already been unset by the Coupler. I've therefore had to roll the change back and go back to the drawing board for now.

On 29 Feb 2012, at 15:21, jeremyharris wrote:

I probably didn't take your reply the right way. Hopefully I wasn't too harsh myself.

Anyway, hopefully you'll get a response from David soon. Did you ever get to try out passing an empty 'file' key in the form (i.e., a hidden field)? That way, the key would exist and the Coupler wouldn't unset the data. I don't think this is a very elegant solution either, but I was curious if you tried it out.

On Tuesday, February 28, 2012 8:41:39 PM UTC-8, Jeremy Burns wrote:
Gosh my reply sounded harsh on you Jeremy - that wasn't my intention. We've commented out the line that unsets the data and it *all seems fine*, which also feels dirty. The user records are saving correctly, we can subsequently add images to user records and all other dedicated image tables that use the coupler are functioning too. I did reach out to David yesterday, hoping to learn more from him so that we can implement this properly and will report back.

Jeremy Burns

On 28 Feb 2012, at 21:15:25, jeremyharris wrote:

I didn't say I agreed with how it worked, I was just explaining what I think the author's intended use case was. The question was if you were missing a setting or doing anything wrong. You weren't, so I just threw out some ideas based on how the Coupler works. Feel free to take it up with the author or create a Coupler that works for you.

I'm glad that an empty image doesn't create garbage data, that thought was based off of what the Coupler does down the road (check the file and populate dirname and basename).

On Tuesday, February 28, 2012 12:06:23 PM UTC-8, Jeremy Burns wrote:
I understand what you are saying but I don't think it's the full answer. It's a perfectly valid use case to have a table that has an optional image in it without the need to have a separate join table. The absence of the image doesn't create any garbage data; the user row is still valid. A bio snap for a user is good example. For the plugin to simply clear the whole data array because the optional image fields aren't populated is nuts. If the fields are empty simply return true and let the main model get on with its work.

Jeremy Burns

On 28 Feb 2012, at 15:45:29, jeremyharris wrote:

It should only unset the data if you are creating the User and it's missing the 'file' key. If you are updating, you shouldn't *need* the 'file' key.

That said, you can probably get away with passing an empty (or a path to a default image) file key when you are creating the User using a hidden field. This should allow the coupler to continue with the save. This may save some empty garbage data that is probably unwanted.

The other solution would be to detach the Coupler behavior at runtime when you don't want it to "force" you to have an image.

The whole point of the Coupler is to tightly couple the physical image to the record, so if the image doesn't exist neither should the record. I tend to create a separate table for attachments for this very reason. A user should be allowed to exist without an image.

On Tuesday, February 28, 2012 5:42:11 AM UTC-8, Jeremy Burns wrote:
I'm using David Persson's media plugin. I have a users table that
contains the fields necessary to link to an image file, but a user
does not have to have an image. When I include the Media.Coupler
behaviour in the User model User->create always fails on User->save
when the user does not have an image because of the beforeSave in
coupler.php:

        function beforeSave(&$Model) {
                if (!$Model->exists()) {
                        if (!isset($Model->data[$Model->alias]['file'])) {
                                 unset($Model->data[$Model->alias]);  <<<--- clears down my User
data
                                return true;
                        }
                } else {

This is unsetting the User data because the file key is missing. If I
comment out the unset my User->save is successful. The Media.Coupler
is working perfectly well for another table that hasMany images in an
associated table.

Is there a setting I need to configure or am I doing something else
wrong?

--
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.
 
 
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php


On Tuesday, February 28, 2012 12:06:23 PM UTC-8, Jeremy Burns wrote:
I understand what you are saying but I don't think it's the full answer. It's a perfectly valid use case to have a table that has an optional image in it without the need to have a separate join table. The absence of the image doesn't create any garbage data; the user row is still valid. A bio snap for a user is good example. For the plugin to simply clear the whole data array because the optional image fields aren't populated is nuts. If the fields are empty simply return true and let the main model get on with its work.

Jeremy Burns

On 28 Feb 2012, at 15:45:29, jeremyharris wrote:

It should only unset the data if you are creating the User and it's missing the 'file' key. If you are updating, you shouldn't *need* the 'file' key.

That said, you can probably get away with passing an empty (or a path to a default image) file key when you are creating the User using a hidden field. This should allow the coupler to continue with the save. This may save some empty garbage data that is probably unwanted.

The other solution would be to detach the Coupler behavior at runtime when you don't want it to "force" you to have an image.

The whole point of the Coupler is to tightly couple the physical image to the record, so if the image doesn't exist neither should the record. I tend to create a separate table for attachments for this very reason. A user should be allowed to exist without an image.

On Tuesday, February 28, 2012 5:42:11 AM UTC-8, Jeremy Burns wrote:
I'm using David Persson's media plugin. I have a users table that
contains the fields necessary to link to an image file, but a user
does not have to have an image. When I include the Media.Coupler
behaviour in the User model User->create always fails on User->save
when the user does not have an image because of the beforeSave in
coupler.php:

        function beforeSave(&$Model) {
                if (!$Model->exists()) {
                        if (!isset($Model->data[$Model->alias]['file'])) {
                                 unset($Model->data[$Model->alias]);  <<<--- clears down my User
data
                                return true;
                        }
                } else {

This is unsetting the User data because the file key is missing. If I
comment out the unset my User->save is successful. The Media.Coupler
is working perfectly well for another table that hasMany images in an
associated table.

Is there a setting I need to configure or am I doing something else
wrong?

--
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.
 
 
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php


--
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.
 
 
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php


On Tuesday, February 28, 2012 8:41:39 PM UTC-8, Jeremy Burns wrote:
Gosh my reply sounded harsh on you Jeremy - that wasn't my intention. We've commented out the line that unsets the data and it *all seems fine*, which also feels dirty. The user records are saving correctly, we can subsequently add images to user records and all other dedicated image tables that use the coupler are functioning too. I did reach out to David yesterday, hoping to learn more from him so that we can implement this properly and will report back.

Jeremy Burns

On 28 Feb 2012, at 21:15:25, jeremyharris wrote:

I didn't say I agreed with how it worked, I was just explaining what I think the author's intended use case was. The question was if you were missing a setting or doing anything wrong. You weren't, so I just threw out some ideas based on how the Coupler works. Feel free to take it up with the author or create a Coupler that works for you.

I'm glad that an empty image doesn't create garbage data, that thought was based off of what the Coupler does down the road (check the file and populate dirname and basename).

On Tuesday, February 28, 2012 12:06:23 PM UTC-8, Jeremy Burns wrote:
I understand what you are saying but I don't think it's the full answer. It's a perfectly valid use case to have a table that has an optional image in it without the need to have a separate join table. The absence of the image doesn't create any garbage data; the user row is still valid. A bio snap for a user is good example. For the plugin to simply clear the whole data array because the optional image fields aren't populated is nuts. If the fields are empty simply return true and let the main model get on with its work.

Jeremy Burns

On 28 Feb 2012, at 15:45:29, jeremyharris wrote:

It should only unset the data if you are creating the User and it's missing the 'file' key. If you are updating, you shouldn't *need* the 'file' key.

That said, you can probably get away with passing an empty (or a path to a default image) file key when you are creating the User using a hidden field. This should allow the coupler to continue with the save. This may save some empty garbage data that is probably unwanted.

The other solution would be to detach the Coupler behavior at runtime when you don't want it to "force" you to have an image.

The whole point of the Coupler is to tightly couple the physical image to the record, so if the image doesn't exist neither should the record. I tend to create a separate table for attachments for this very reason. A user should be allowed to exist without an image.

On Tuesday, February 28, 2012 5:42:11 AM UTC-8, Jeremy Burns wrote:
I'm using David Persson's media plugin. I have a users table that
contains the fields necessary to link to an image file, but a user
does not have to have an image. When I include the Media.Coupler
behaviour in the User model User->create always fails on User->save
when the user does not have an image because of the beforeSave in
coupler.php:

        function beforeSave(&$Model) {
                if (!$Model->exists()) {
                        if (!isset($Model->data[$Model->alias]['file'])) {
                                 unset($Model->data[$Model->alias]);  <<<--- clears down my User
data
                                return true;
                        }
                } else {

This is unsetting the User data because the file key is missing. If I
comment out the unset my User->save is successful. The Media.Coupler
is working perfectly well for another table that hasMany images in an
associated table.

Is there a setting I need to configure or am I doing something else
wrong?

--
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.
 
 
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php


On Tuesday, February 28, 2012 12:06:23 PM UTC-8, Jeremy Burns wrote:
I understand what you are saying but I don't think it's the full answer. It's a perfectly valid use case to have a table that has an optional image in it without the need to have a separate join table. The absence of the image doesn't create any garbage data; the user row is still valid. A bio snap for a user is good example. For the plugin to simply clear the whole data array because the optional image fields aren't populated is nuts. If the fields are empty simply return true and let the main model get on with its work.

Jeremy Burns

On 28 Feb 2012, at 15:45:29, jeremyharris wrote:

It should only unset the data if you are creating the User and it's missing the 'file' key. If you are updating, you shouldn't *need* the 'file' key.

That said, you can probably get away with passing an empty (or a path to a default image) file key when you are creating the User using a hidden field. This should allow the coupler to continue with the save. This may save some empty garbage data that is probably unwanted.

The other solution would be to detach the Coupler behavior at runtime when you don't want it to "force" you to have an image.

The whole point of the Coupler is to tightly couple the physical image to the record, so if the image doesn't exist neither should the record. I tend to create a separate table for attachments for this very reason. A user should be allowed to exist without an image.

On Tuesday, February 28, 2012 5:42:11 AM UTC-8, Jeremy Burns wrote:
I'm using David Persson's media plugin. I have a users table that
contains the fields necessary to link to an image file, but a user
does not have to have an image. When I include the Media.Coupler
behaviour in the User model User->create always fails on User->save
when the user does not have an image because of the beforeSave in
coupler.php:

        function beforeSave(&$Model) {
                if (!$Model->exists()) {
                        if (!isset($Model->data[$Model->alias]['file'])) {
                                 unset($Model->data[$Model->alias]);  <<<--- clears down my User
data
                                return true;
                        }
                } else {

This is unsetting the User data because the file key is missing. If I
comment out the unset my User->save is successful. The Media.Coupler
is working perfectly well for another table that hasMany images in an
associated table.

Is there a setting I need to configure or am I doing something else
wrong?

--
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.
 
 
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php


--
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.
 
 
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php


--
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.
 
 
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php