Re: [fw-general] Best practices for managing ZF2 modules and dependencies
After doing some more searching I came upon this: https://getcomposer.org/doc/faqs/how-do-i-install-a-package-to-a-custom-path-for-my-framework.md I ended up implementing this and it worked perfectly having my package use composer/install with the "zend-module" type. Thanks for the help all! On Wed, Mar 11, 2015 at 11:09 PM, Andy Baird wrote: > Hi everyone, > > Thank you all for the fantastic advice. I am now working on implementing a > solution that uses --prefer-source and I'm running into two problems that > Google didn't solve. > > I apologize as these are more composer specific than Zend, but it sounds > like several members may have experience with this already. > >- Is there a way to set --prefer-source on a per package basis? I >found the config stub option for composer.json, but that seems to affect >all packages. >- Like the first question, is there a way to set a specific directory >for the checkout of specific packages? For example, I'd love to clone the >custom modules into the module directory instead of /vendor. Again I see >how I can set this globally, but I'm unsure if this can be done on a per >package basis. > > Thanks, > > -Andy > > > On Thu, Feb 12, 2015 at 1:10 AM, Michael Gooden < > mich...@bluepointevents.com> wrote: > >> Hi, >> >> You could also take the approach similiar to Zend Framework 2 itself, >> wherein all the code lies in a single repository, with a master >> composer.json that does a "replace self.version" for all your modules. You >> use this during development with --prefer-source, which should make it easy >> to develop the code. >> >> In parallel, you maintain composer.json files within each module path >> that describe the dependencies of that specific modules. For production >> deployment, you use the script that ZF2 uses, to break the main repo into >> individual composer repositories. >> >> I must say, Vincent's approach does seem more structured than this. YMMV. >> >> >> Kind Regards, >> >> *Michael Gooden* >> CEO >> >> >> *Blue Point Events (Pty) Ltd* >> >> Jutland Crescent, St Georges Park, Port Elizabeth, 6001 >> >> PO Box 63941, Greenacres, Port Elizabeth, 6057 >> >> M: +27 76 489 1764 | F: +27 86 551 2556 >> >> mich...@bluepointevents.com >> >> Skype: michael.bluepointweb >> >> *NOTICE OF CONFIDENTIALITY* >> The preceding e-mail message (including any attachments) contains >> information that may be confidential, may be protected by the >> attorney-client or other applicable privileges, or may constitute >> non-public information. It is intended to be conveyed only to the >> designated recipient(s) named above. If you are not an intended recipient >> of this message, please notify the sender by replying to this message and >> then delete all copies of it from your computer system. Any use, >> dissemination, distribution, or reproduction of this message by unintended >> recipients is not authorized and may be unlawful. >> >> On 12 February 2015 at 02:48, Vincent Caggiari >> wrote: >> >>> Hello, >>> >>> We tried exactly the same thing (same modules for different clients) but >>> things got so complicated to manage that we stopped to build websites >>> this >>> way. >>> Why it became so complicated : >>> >>>- Same code base for different clients doesn't allow you to customize >>>them so when a client has a specific use case/need, you can't do it >>> (and >>>don't tell me that you will create a new module for this client which >>> will >>>override the first one for the parts you need to customize because >>> you will >>>have 2 modules doing the same thing and when you will have to do some >>>changes, you will not remember in which one to look). >>>- You MUST have one repository per module, it's easier to manage and >>> see >>>what your developers are doing. If you need to update only one module >>> (i.e >>>patch), you can then update your project easily with only the change >>> you >>>need (so you don't pull changes made on another module which can >>> introduce >>>bugs for a specific client or some merging headache). >>> >>> >>> At this time, we have one repository per module. Each module for each >>> client is forked from our "module" core codebase so when a change is made >>> for a client and can be used by another (generic change), you update your >>> client module, then make a pull request to the "module" core codebase >>> which >>> is then approved and incorporated. >>> Then, when you need to work on another client which use the same module, >>> you update your client's one by pulling the "module" core codebase, merge >>> the changes with the customized one, test and voila. >>> >>> Regards, >>> CAGGIARI Vincent. >>> >> >> >
Re: [fw-general] Best practices for managing ZF2 modules and dependencies
Hi everyone, Thank you all for the fantastic advice. I am now working on implementing a solution that uses --prefer-source and I'm running into two problems that Google didn't solve. I apologize as these are more composer specific than Zend, but it sounds like several members may have experience with this already. - Is there a way to set --prefer-source on a per package basis? I found the config stub option for composer.json, but that seems to affect all packages. - Like the first question, is there a way to set a specific directory for the checkout of specific packages? For example, I'd love to clone the custom modules into the module directory instead of /vendor. Again I see how I can set this globally, but I'm unsure if this can be done on a per package basis. Thanks, -Andy On Thu, Feb 12, 2015 at 1:10 AM, Michael Gooden wrote: > Hi, > > You could also take the approach similiar to Zend Framework 2 itself, > wherein all the code lies in a single repository, with a master > composer.json that does a "replace self.version" for all your modules. You > use this during development with --prefer-source, which should make it easy > to develop the code. > > In parallel, you maintain composer.json files within each module path that > describe the dependencies of that specific modules. For production > deployment, you use the script that ZF2 uses, to break the main repo into > individual composer repositories. > > I must say, Vincent's approach does seem more structured than this. YMMV. > > > Kind Regards, > > *Michael Gooden* > CEO > > > *Blue Point Events (Pty) Ltd* > > Jutland Crescent, St Georges Park, Port Elizabeth, 6001 > > PO Box 63941, Greenacres, Port Elizabeth, 6057 > > M: +27 76 489 1764 | F: +27 86 551 2556 > > mich...@bluepointevents.com > > Skype: michael.bluepointweb > > *NOTICE OF CONFIDENTIALITY* > The preceding e-mail message (including any attachments) contains > information that may be confidential, may be protected by the > attorney-client or other applicable privileges, or may constitute > non-public information. It is intended to be conveyed only to the > designated recipient(s) named above. If you are not an intended recipient > of this message, please notify the sender by replying to this message and > then delete all copies of it from your computer system. Any use, > dissemination, distribution, or reproduction of this message by unintended > recipients is not authorized and may be unlawful. > > On 12 February 2015 at 02:48, Vincent Caggiari > wrote: > >> Hello, >> >> We tried exactly the same thing (same modules for different clients) but >> things got so complicated to manage that we stopped to build websites this >> way. >> Why it became so complicated : >> >>- Same code base for different clients doesn't allow you to customize >>them so when a client has a specific use case/need, you can't do it >> (and >>don't tell me that you will create a new module for this client which >> will >>override the first one for the parts you need to customize because you >> will >>have 2 modules doing the same thing and when you will have to do some >>changes, you will not remember in which one to look). >>- You MUST have one repository per module, it's easier to manage and >> see >>what your developers are doing. If you need to update only one module >> (i.e >>patch), you can then update your project easily with only the change >> you >>need (so you don't pull changes made on another module which can >> introduce >>bugs for a specific client or some merging headache). >> >> >> At this time, we have one repository per module. Each module for each >> client is forked from our "module" core codebase so when a change is made >> for a client and can be used by another (generic change), you update your >> client module, then make a pull request to the "module" core codebase >> which >> is then approved and incorporated. >> Then, when you need to work on another client which use the same module, >> you update your client's one by pulling the "module" core codebase, merge >> the changes with the customized one, test and voila. >> >> Regards, >> CAGGIARI Vincent. >> > >
Re: [fw-general] Zend_Session::start causes Apache to hang after the session is created
Would terminating the request early using exit() cause the session file to remain locked? On Sat, Feb 13, 2010 at 9:22 AM, Andy Baird wrote: > Hey Konr, > > I don't have any long running requests, but it does work if I delete the > cookie and refresh. > > -Andy > > > On Sat, Feb 13, 2010 at 6:54 AM, Konr Ness wrote: > >> Sounds like your session might be getting locked. This would happen if >> your sessions are being written to the filesystem (PHP default) and a PHP >> request doesn't complete or hangs. This would cause your session to remain >> locked and all subsequent requests would hang waiting for the session to >> unlock. >> >> Do you have any long-running requests on the same server? >> >> If you delete your cookie and refresh the page, does it work at least the >> first time? >> >> Konr >> >> >> On Sat, Feb 13, 2010 at 1:19 AM, Andy Baird wrote: >> >>> I'm having an issue after installing a Zend Framework application on a >>> shared host environment. >>> >>> The app itself works fine until I try to login. I'm using Zend_Session as >>> the session mechanism. As soon as I try to log in, the application >>> completely indefinitely hangs. >>> >>> This happens after a session object has been created on the server for a >>> client. I've narrowed it down to the second Zend_Session::start() call that >>> gets made. >>> >>> I know the site worked perfectly fine on my own server (CentOS5.3 with >>> php 5.2) >>> >>> Anyone ever had any similar problems? >>> >> >> >
Re: [fw-general] Zend_Session::start causes Apache to hang after the session is created
Hey Konr, I don't have any long running requests, but it does work if I delete the cookie and refresh. -Andy On Sat, Feb 13, 2010 at 6:54 AM, Konr Ness wrote: > Sounds like your session might be getting locked. This would happen if your > sessions are being written to the filesystem (PHP default) and a PHP request > doesn't complete or hangs. This would cause your session to remain locked > and all subsequent requests would hang waiting for the session to unlock. > > Do you have any long-running requests on the same server? > > If you delete your cookie and refresh the page, does it work at least the > first time? > > Konr > > > On Sat, Feb 13, 2010 at 1:19 AM, Andy Baird wrote: > >> I'm having an issue after installing a Zend Framework application on a >> shared host environment. >> >> The app itself works fine until I try to login. I'm using Zend_Session as >> the session mechanism. As soon as I try to log in, the application >> completely indefinitely hangs. >> >> This happens after a session object has been created on the server for a >> client. I've narrowed it down to the second Zend_Session::start() call that >> gets made. >> >> I know the site worked perfectly fine on my own server (CentOS5.3 with php >> 5.2) >> >> Anyone ever had any similar problems? >> > >
[fw-general] Zend_Session::start causes Apache to hang after the session is created
I'm having an issue after installing a Zend Framework application on a shared host environment. The app itself works fine until I try to login. I'm using Zend_Session as the session mechanism. As soon as I try to log in, the application completely indefinitely hangs. This happens after a session object has been created on the server for a client. I've narrowed it down to the second Zend_Session::start() call that gets made. I know the site worked perfectly fine on my own server (CentOS5.3 with php 5.2) Anyone ever had any similar problems?
[fw-general] Zend_Filter_Input filtering not triggering
Hi all,
I'm using Zend_Filter_Input on my magic getter / setter methods to validate
my input and cast fields to the type I desire.
The validation portion is working great, but it's like the filters aren't
working at all.
My model, with Zend_Filter_Input logic, is here:
http://pastebin.com/m7950c5a0
Example output is here:
object(MyApp_Model_User)#19 (1) {
["_data:protected"]=>
array(15) {
["id"]=>
string(1) "4"
["email"]=>
string(19) "andyba...@gmail.com"
["password"]=>
string(32) "594851275f207072b172d7508f037d78"
["username"]=>
string(6) "abaird"
["first"]=>
string(4) "Andy"
["last"]=>
string(5) "Baird"
["phone"]=>
string(10) "111222"
["email_opt_in"]=>
int(1)
["zip"]=>
string(5) "5"
["birthyear"]=>
string(4) "1984"
["gender"]=>
string(4) "male"
["activated"]=>
int(1)
["date_joined"]=>
string(10) "2008-03-11"
["admin"]=>
string(1) "1"
["active"]=>
string(1) "1"
}
}
I can't figure out if it's a usage error, but I've tried tracing through the
code and can't figure out why the filters don't seem to be applying.
Any insight on this would be appreciated!
-Andy
