Menu
▾
▴
cep-development — CEP development list
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(5) |
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(11) |
Feb
(2) |
Mar
(7) |
Apr
(7) |
May
(9) |
Jun
(16) |
Jul
(3) |
Aug
(10) |
Sep
(5) |
Oct
|
Nov
(4) |
Dec
(18) |
| 2005 |
Jan
(9) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2005-10-21 22:08:04
|
Task #120440 has been updated. Project: Core Enterprise PHP Subproject: Unit testing Summary: do something Complete: 0% Status: Open Authority : jaxn Assigned to: jaxn Description: sdfdsf ------------------------------------------------------- For more info, visit: http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=120440&group_id=94938&group_project_id=36969 |
|
From: Jackson M. <ja...@te...> - 2005-01-24 14:04:11
|
I would rather there be a mapping of events and handlers similar to how
we have mapped pages to modules. That was multiple events can be
handled by the same handler. This also means there is a single place
where all of the application event handlers are defined.
The "listener" would handle all events. This would likely be in the
front controller (or called from the front controller).
So, no, I don't think the observer pattern is what we are looking for
here. My understanding of the observer pattern is that we would either
have to load all of the event handlers on every request or we would
have to wait to fire an event until we got to the component that fired
the event (since HTTP is stateless).
Feel free to correct me if I am wrong on that one.
-Jackson
On Jan 22, 2005, at 11:22 AM, Marcus Whitney wrote:
> Hey,
>
> So, I have a question. How have events/listeners been implemented in
> Axson, and would that implementation work well with CEP. Or should we
> simply consider an observable interface that all overloading classes
> would implement?
> interface Observable {
> function attach( Observer $observer);
> function detach( Observer $observer);
> function notify();
> }
>
> interface Observer {
> function run( Observable $observable);
> }
>
> Is there something more elegant? should there be more ability to
> define events? I'm still figuring it all out, but pretty fast so I'm
> ready to put something in place ASAP.
>
> Lemme know. Thanks.
>
> - Marcus
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> Cep-development mailing list
> Cep...@li...
> https://lists.sourceforge.net/lists/listinfo/cep-development
>
|
|
From: Marcus W. <ma...@ph...> - 2005-01-23 17:26:54
|
http://www.akbkhome.com/blog.php/View/67/Hype+by+blog..html#comments |
|
From: Marcus W. <ma...@ph...> - 2005-01-22 17:25:31
|
Hey,
So, I have a question. How have events/listeners been implemented in
Axson, and would that implementation work well with CEP. Or should we
simply consider an observable interface that all overloading classes
would implement?
interface Observable {
function attach( Observer $observer);
function detach( Observer $observer);
function notify();
}
interface Observer {
function run( Observable $observable);
}
Is there something more elegant? should there be more ability to define
events? I'm still figuring it all out, but pretty fast so I'm ready to
put something in place ASAP.
Lemme know. Thanks.
- Marcus
|
|
From: Marcus W. <ma...@ph...> - 2005-01-19 18:40:52
|
Yup, you're right. All in our own time though, right :) Jackson Miller wrote: > Marcus Whitney wrote: > >> I no longer care about PHP 4. > > > It is about damn time! > > -Jackson > >> >> >> ------------------------------------------------------- >> The SF.Net email is sponsored by: Beat the post-holiday blues >> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. >> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt >> _______________________________________________ >> Cep-development mailing list >> Cep...@li... >> https://lists.sourceforge.net/lists/listinfo/cep-development >> > |
|
From: Jackson M. <ja...@ja...> - 2005-01-19 14:28:53
|
Marcus Whitney wrote: > I no longer care about PHP 4. It is about damn time! -Jackson > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > Cep-development mailing list > Cep...@li... > https://lists.sourceforge.net/lists/listinfo/cep-development > |
|
From: Marcus W. <ma...@ph...> - 2005-01-19 04:24:32
|
I no longer care about PHP 4. |
|
From: Marcus W. <ma...@ph...> - 2005-01-08 01:11:12
|
1800vehicles.com unified-php.net That's all. |
|
From: Marcus W. <ma...@ph...> - 2005-01-07 19:28:44
|
Ok, I'm going to use CEP as the playground for my research in PHPUnit2 for the book and the Rephlux tie-in. This heralds in a new era.... because.... if I write these tests, and someone else (Jaxn) codes first, then the tests become worthless. So. TEST FIRST!!! I will write a good amount of well documented Tests for everyone to follow. If we can stick with this, we can achieve Continuous Integration. Please comply... thanks :) - Marcus. |
|
From: Marcus W. <ma...@ph...> - 2005-01-06 22:06:48
|
Hey, So, I'm trying to think about what is wrong with the idea of standardizing on storing and returning data as UTF-8, and making Modules the common public API of all applications, and I can't figure that out. UTF-8 is the XML character set of choice, which means this is the highest level of interoperability we could achieve. It's anal to insist on it, but... I believe it's a step in the right direction. It puts us in a better place for data transformation and I18n. Also, it's a great way to separate business logic and display logic. For example, it would be sweet if I could access the same module like so: From a Web Browser: http://example.com/web_transport/view:MyView/state:MyState/param1:MyParam1 From a REST Web Service: http://example.com/rest_transport.php?view=MyView&state=MyState¶m1=MyParam1 FROM a SOAP Client: | <?php $client = new SoapClient(NULL, array( "location" => "http://example.com/soap_transport", "uri" => "urn:cep-view", "style" => SOAP_RPC, "use" => SOAP_ENCODED )); print($client->__call( /* SOAP Method Name */ "MyView", /* Parameters */ array( new SoapParam( /* Parameter Value */ "MyState", /* Parameter Name */ "state" ), || new SoapParam( /* Parameter Value */ "MyParam1", /* Parameter Name */ "param1" )||), /* Options */ array( /* SOAP Method Namespace */ "uri" => "urn:xmethods-delayed-quotes", /* SOAPAction HTTP Header for SOAP Method */ "soapaction" => "urn:cep-view#MyView" )). "\n"); ?> | of course a WSDL would simplify the above SOAP call. FROM the Command Line: cli_transport --view=MyView --state=MyState --param1=MyParam1 Then we could each module essentially do the same thing, except transform the XML according to the transport used. Where that logic should be, I'm not certain, but I don't just want component reusablity, I want API abstraction as well. XSL is performs pretty damn well in PHP5 in my tests so far. I think it really could do the job of making the XML into an appropriate output format. What I would love to see is a PHP Class that gave me an IT like interface to create XSLT tags. That would be nice. I wonder if modules (or pages or components or what the hell ever!!!) should have render methods for the various transports. So if one isn't present, the basic XML is returned, however if one exists it is used to transform the XML. I think I'm going to play with this idea in a module and see how I like it... thoughts, insight, rants, counter-points are very welcomed. |
|
From: Marcus W. <ma...@ph...> - 2004-12-31 17:33:07
|
Jackson Miller wrote: > Marcus Whitney wrote: > >> First of all... these ideas aren't new, not even to CEP discussion. >> I recall many convos where Jaxn suggested XSLT and having modules >> simply return XML. I'm just catching up, we work that way sometimes. > > > If I recall correctly, you talked me out of using XML/XSLT in those > convos. I guess now it is my turn. We work that way sometimes too. :) Hah. > >> >> The basic premise is that Modules are the one public universal API >> for requesting activity from CEP. Bootstraps can handle Module >> requests differently (web request, XML-RPC, SOAP, REST, CEP Clean >> URL, etc.), but the API itself would never change and never require >> any changes to the transports to add functionality. > > > Agreed. > ok. >> >> Libraries are primarily for data access. They could serve other >> purposes... which brings a question for the spec. Are libraries >> really just namespaced method packages? I'm starting to think I like >> that instead of all the ORM, DataObject stuff. Seems too involved >> for our spec, but anyway.... > > > I am starting to think along the lines of "Business Objects" to > perform logic, "Transfer Objects" to provide and OOP representation > of the data, and "Data Access Layer" to abstract raw database calls > that can be tweaked for performance, but anyway... > ok. I'm not sure where this will go beyond preference. I could go either way. >> >> Components are reusable interface widgets essentially. They are not >> modules, period. My thinking here is that components follow a basic >> model. The one we have now would serve the purpose. Now, the >> important thing is, anyone can write any component they want. So, if >> I like QuickForm, Jaxn like PHPObjects and Patrick likes PatForms, we >> could all wrap those packages into different CEP components. Or, >> they could all suck and we wrote our own. The point being, the >> component isn't core, the component model is. A healthy diverse >> component repository would be encouraged in this model. > > > I think I agree, but I am starting to wonder what the hell modules > are. I know that the original idea behind modules was similar to > kernel modules in that if they are present then they are functional > while if they aren't present then they aren't needed. It was along > the lines of "if there is a comments module available, provide comment > functionality on the blog, if not then don't" and that you could > choose which "comments module" you wanted to use. That idea was back > in the "cataBlog" days, pre CEP-0.1. While it is a good idea, it does > not describe the functioality of components at all. Modules are public Application API. > > I do think that we have been loosly referring to "pages" as modules, > and that may not be accurate. > I think "Pages" are just unique identifiers, like a namespace or something. It all goes back to request / response. HTTP method calls and XML data is what moves in and out of the application. Modules, to me, is the public API of the application. Bootstraps just wrap the requests in a particular transport with a particular vernacular. "Pages" is a concept, which could be called anything else that served as a unique identifier for a registered instance of a module. > I also love the flexibility we offer developers. I was thinking today > about writing an article called "CEP c.r.u.d. tools: variations on a > theme" just for fun. Nice. > >> >> Modules can be called from within other Modules natively as they are >> part of CEP ($module = new Module), or then can be requested through >> any of the transport bootstraps, either way, the returned value >> should be valid UTF-8 XML. > > > How is that different from components? > The main thing I would think about components is that they aren't registered. If the component model and the module model were the exact same (which they can be), the one thing that would differentiate the two is the cep_modules table in the schema. Of course, many times you can logically discern when a body of code should be either a component or a module. Just because they are interoperable doesn't mean that many components would ever be used as a registered module. I think components are more like developers tools, and modules are like plug and play tools for the everyday user. It may be clearer to think of these in this way than in a code way? >> >> The XSLT aspect can be left out since you can return valid XML/XHTML >> from a module, or it can always be used, since XSLT always works on >> valid XML. Up the the developer. Again, this isn't core, however >> forcing all modules to return valid UTF-8 XML would be a core >> requirement. > > > What is the advantage of making it UTF-8? I agree that we should make > all XML be valid (including HTML), but why UTF-8 encoding? I also > agree about leaving XSLT out. That goes against the "PHP is a > templating language" argument and seems like double parsing to me. I > am all for having the option, just wouldn't want to require it. ok. The advantage would be that UTF-8 is the default char set for XML and by mandate supported by all XML parsers: http://www.w3.org/TR/REC-xml/#charencoding I understand the point made however. This is an idea I'm experimenting with. I'm not all the way with it, however I'm beginning to think that XML/XSL is the best way to start a presentation object. > >> >> The diagram is attached, lemme know what you think. This is just a >> brainstorm. >> >> Side Note: This diagram offers PHP4 and PHP5 suggested package >> notes. My hope is that this, or something similar, could be achieved >> in both branches, I don't think PHP4 is dead just yet, although PHP5 >> is far more elegant. > > > I like the diagram. I ommitted it from the reply to save bandwidth. Thanks. > > > PHP4 may not be dead, but it is "dead to me". I do however appreciate > your willingness to still support it in some capacity. Understandable. I think that PHP5 is still on it's way. Like I said, it's more elegant and powerful in a lot of ways, however PHP 4 is still the one in production for the big apps of today, and in some camps a PHP4 implementation of CEP will be a lot less daunting of a switch than a jump to 5 and a new framework. People are still trying to figure out PHP5. Friendster and Flickr are still PHP4 at the moment. > > Just an FYI, I am dealing with some of the same issues and have > blogged a little comparison (including a little diagram of my own at > the bottom). > http://jaxn.org/blog/archives/522-Developing-Component-Based-Web-Applications.html > interesting read. Look forward to seeing good things from Axson I'm off to work on the book. - Marcus |
|
From: Jackson M. <ja...@ja...> - 2004-12-31 04:58:38
|
Marcus Whitney wrote: > First of all... these ideas aren't new, not even to CEP discussion. I > recall many convos where Jaxn suggested XSLT and having modules simply > return XML. I'm just catching up, we work that way sometimes. If I recall correctly, you talked me out of using XML/XSLT in those convos. I guess now it is my turn. We work that way sometimes too. :) > > The basic premise is that Modules are the one public universal API for > requesting activity from CEP. Bootstraps can handle Module requests > differently (web request, XML-RPC, SOAP, REST, CEP Clean URL, etc.), > but the API itself would never change and never require any changes to > the transports to add functionality. Agreed. > > Libraries are primarily for data access. They could serve other > purposes... which brings a question for the spec. Are libraries > really just namespaced method packages? I'm starting to think I like > that instead of all the ORM, DataObject stuff. Seems too involved for > our spec, but anyway.... I am starting to think along the lines of "Business Objects" to perform logic, "Transfer Objects" to provide and OOP representation of the data, and "Data Access Layer" to abstract raw database calls that can be tweaked for performance, but anyway... > > Components are reusable interface widgets essentially. They are not > modules, period. My thinking here is that components follow a basic > model. The one we have now would serve the purpose. Now, the > important thing is, anyone can write any component they want. So, if > I like QuickForm, Jaxn like PHPObjects and Patrick likes PatForms, we > could all wrap those packages into different CEP components. Or, they > could all suck and we wrote our own. The point being, the component > isn't core, the component model is. A healthy diverse component > repository would be encouraged in this model. I think I agree, but I am starting to wonder what the hell modules are. I know that the original idea behind modules was similar to kernel modules in that if they are present then they are functional while if they aren't present then they aren't needed. It was along the lines of "if there is a comments module available, provide comment functionality on the blog, if not then don't" and that you could choose which "comments module" you wanted to use. That idea was back in the "cataBlog" days, pre CEP-0.1. While it is a good idea, it does not describe the functioality of components at all. I do think that we have been loosly referring to "pages" as modules, and that may not be accurate. I also love the flexibility we offer developers. I was thinking today about writing an article called "CEP c.r.u.d. tools: variations on a theme" just for fun. > > Modules can be called from within other Modules natively as they are > part of CEP ($module = new Module), or then can be requested through > any of the transport bootstraps, either way, the returned value should > be valid UTF-8 XML. How is that different from components? > > The XSLT aspect can be left out since you can return valid XML/XHTML > from a module, or it can always be used, since XSLT always works on > valid XML. Up the the developer. Again, this isn't core, however > forcing all modules to return valid UTF-8 XML would be a core > requirement. What is the advantage of making it UTF-8? I agree that we should make all XML be valid (including HTML), but why UTF-8 encoding? I also agree about leaving XSLT out. That goes against the "PHP is a templating language" argument and seems like double parsing to me. I am all for having the option, just wouldn't want to require it. > > The diagram is attached, lemme know what you think. This is just a > brainstorm. > > Side Note: This diagram offers PHP4 and PHP5 suggested package notes. > My hope is that this, or something similar, could be achieved in both > branches, I don't think PHP4 is dead just yet, although PHP5 is far > more elegant. I like the diagram. I ommitted it from the reply to save bandwidth. PHP4 may not be dead, but it is "dead to me". I do however appreciate your willingness to still support it in some capacity. Just an FYI, I am dealing with some of the same issues and have blogged a little comparison (including a little diagram of my own at the bottom). http://jaxn.org/blog/archives/522-Developing-Component-Based-Web-Applications.html -Jackson |
|
From: Marcus W. <ma...@ph...> - 2004-12-30 07:15:18
|
First of all... these ideas aren't new, not even to CEP discussion. I recall many convos where Jaxn suggested XSLT and having modules simply return XML. I'm just catching up, we work that way sometimes. The basic premise is that Modules are the one public universal API for requesting activity from CEP. Bootstraps can handle Module requests differently (web request, XML-RPC, SOAP, REST, CEP Clean URL, etc.), but the API itself would never change and never require any changes to the transports to add functionality. Libraries are primarily for data access. They could serve other purposes... which brings a question for the spec. Are libraries really just namespaced method packages? I'm starting to think I like that instead of all the ORM, DataObject stuff. Seems too involved for our spec, but anyway.... Components are reusable interface widgets essentially. They are not modules, period. My thinking here is that components follow a basic model. The one we have now would serve the purpose. Now, the important thing is, anyone can write any component they want. So, if I like QuickForm, Jaxn like PHPObjects and Patrick likes PatForms, we could all wrap those packages into different CEP components. Or, they could all suck and we wrote our own. The point being, the component isn't core, the component model is. A healthy diverse component repository would be encouraged in this model. Modules can be called from within other Modules natively as they are part of CEP ($module = new Module), or then can be requested through any of the transport bootstraps, either way, the returned value should be valid UTF-8 XML. The XSLT aspect can be left out since you can return valid XML/XHTML from a module, or it can always be used, since XSLT always works on valid XML. Up the the developer. Again, this isn't core, however forcing all modules to return valid UTF-8 XML would be a core requirement. The diagram is attached, lemme know what you think. This is just a brainstorm. Side Note: This diagram offers PHP4 and PHP5 suggested package notes. My hope is that this, or something similar, could be achieved in both branches, I don't think PHP4 is dead just yet, although PHP5 is far more elegant. |
|
From: Jackson M. <ja...@ph...> - 2004-12-16 13:47:20
|
Marcus Whitney wrote: > Let's start discussing the relationship between Conf and Request. CEP_Conf will replace the definition of constants in cep.conf.php (which will no longer exist). CEP_Conf will be stored in the session to allow for per-user configurations. CEP_Request on the other hand will be used to stooore information that is only applicable to the current request. This would be for things like when a component needs to inject something into the HEAD or OnLoad for a response. Also, CEP_Request will get rid of the cep_get_vars array. Historically we could craft a new cep_get_vars array to embed a component within another component. Now we could use the clone to copy the current request and then alter the settings that we need to alter. Discussion started. -Jackson |
|
From: Marcus W. <ma...@ph...> - 2004-12-16 06:12:34
|
Jackson Miller wrote: >I have added a shell of a CEP_Config object and renamed the CEP_User file from >CEP/CEP_User.php to CEP/User.php as it should have been. > > Nice. Let's start discussing the relationship between Conf and Request. >I also added an __autoload() implementation to the CEP base class. If someone >is going to implement CEP on their page then they must include CEP. If we >agree that this is a good idea then we can quit making include statements >that follow the CEP naming convention, but this would require CEP to be in >the include_path. > > CEP should be in the inlude_path. >Also, after User/Request/Conf is done, if we have autoload we can start >playing with a "aspect" implementation to complete the CLAM model. > > Right on. There is a Request stub. I've got a CEP 0.3 / PHP 5.0.2 / PostgreSQL 8.0 install running on my laptop right now, so I'm ready to get to work. >-Jackson > > >------------------------------------------------------- >SF email is sponsored by - The IT Product Guide >Read honest & candid reviews on hundreds of IT Products from real users. >Discover which products truly live up to the hype. Start reading now. >http://productguide.itmanagersjournal.com/ >_______________________________________________ >Cep-development mailing list >Cep...@li... >https://lists.sourceforge.net/lists/listinfo/cep-development > > |
|
From: Jackson M. <ja...@ph...> - 2004-12-16 04:17:56
|
I have added a shell of a CEP_Config object and renamed the CEP_User file from CEP/CEP_User.php to CEP/User.php as it should have been. I also added an __autoload() implementation to the CEP base class. If someone is going to implement CEP on their page then they must include CEP. If we agree that this is a good idea then we can quit making include statements that follow the CEP naming convention, but this would require CEP to be in the include_path. Also, after User/Request/Conf is done, if we have autoload we can start playing with a "aspect" implementation to complete the CLAM model. -Jackson |
|
From: Jackson M. <jm...@ma...> - 2004-12-15 20:18:40
|
I have created a DOAP (description of a project) file for CEP at doap.net. It is available here: http://doap.net/CEP Like most things CEP, it is currently incomplete. -Jackson |
|
From: Jackson M. <ja...@ph...> - 2004-12-12 18:12:06
|
Marcus and I have been talking a little bit over IM the past couple of days trying to iron out some thoughts on the stuff in CEP that happens before a page module is loaded. Here is the proposed idea: There are three new objects that will be a part of every CEP request: 1) CEP_Config - replaces the (expensive) declaration of all those constants. 2) CEP_User - replaces the messy auth implementation and the nasty permissions array with a much more accessible OO interface. 3) CEP_Request - wraps up some information about the GET and POST variables. Controlling this allows us to use clean and dirty URLs and do some fancy stuff with objects in forms (and entire forms as objects). This object will most likely also contain cepCreateUrl() for creating new CEP requests (links, form actions, etc). CEP_User is mostly working, and I have implemented it on my laptop, but I need someway to convert the requested string into a page module to load, so I am now working on the Config class. Marcus is starting to think about the Request object. CEP_User and CEP_Config will be cached in the session. CEP_Request may be cached in the session. Caching the request object would make it easy for us to keep a history of a particular user's requests (for going "back" after performing an action, etc). But it will be a few days before we get there. -Jackson |
|
From: Jackson M. <ja...@ph...> - 2004-12-11 23:22:21
|
I have been playing with a CEP_User object cached in the session. It is working pretty well but I still have some bugs to fix before I am going to commit the implementation to CVS. One "problem" I have come up against is that in order to cache objects in the session, they must be available before session_start() is called. This won't work if session_autostart is turned on in the ini file. I don't know the performance implications of having to call session_start, but I think that would be less than ideal. The other options would be: Defining an __autoload method for CEP. This would be global for all PHP run during the CEP request, which would limit the ability to incorporate third party packages that also use autoload. However, we will need autoload anyway once we start doing the "aspect" part of CLAMs. The final option would be to provide CEP_User as a PECL compiled class and put that in PHP.ini with session_autostart. I think this option completely sucks too. I think that autoload is the best option, and it probably wouldn't be a problem at all if we had namespaces, but ... Thoughts? -Jackson |
|
From: Jackson M. <ja...@ph...> - 2004-12-10 05:17:18
|
I have committed and flushed out a CEP_User class. It is mostly documented. I like the current schema setup, so I am going to leave that alone. Take a look and let me know what you think of the method names. After I have this working I will move on to classes that allow us to manage the users/permissions/groups etc. We have modules for that interface, but I would like user and group "data objects". -Jackson |
|
From: Jackson M. <ja...@ph...> - 2004-12-10 04:26:03
|
On Thursday 09 December 2004 13:19, Marcus Whitney wrote: > Jackson Miller wrote: > > > > Also, by putting the CEP_User object in the session, it persists > > across requests, reduces the overhead of object creation (object only > > created once per session), and gives global access. > > agreed. Can we get some requirements of the auth package/CEP_User > object down before we lockdown the API? Even if the above meets what > the requirements end up being? > Lock down the API? We ain'tbeta yet ;) Here is what I think we need to be able to do: - login - logout - verify a user is authenticated - check is a user is a member of a group - check if a member has a particular level of permission for a cep_object - get all groups a uses is a member of - get all permissions - be able to refresh permissions on every request via a global config option (mostly for debugging) - get a user's properties (id, email, username, password,etc) - refresh the permission on demand (after adding a right or a group, etc) - a user should maintain their highest level of permission on a cep_object (in cases where they have multiple perms for the same object via groups) Therefore this would be some (not all) of the methods. > > CEP_User::doLogin($username, $password); > > CEP_User::isAuthenticated(); // may be redundant > > CEP_User::getUserID(); > > CEP_User::checkGroup($group); > > CEP_User::checkPerm($cep_object_id,$level); > > CEP_User::doLogout(); -Jackson |
|
From: Jackson M. <ja...@ph...> - 2004-12-10 04:17:12
|
On Sunday 05 December 2004 20:04, Marcus Whitney wrote: > Hey guys. > > I asked Patrick to jack a template from this other PHP web framework, > and he did :) Here is the result: > > http://www.peroro.net/extranet_cep/ Nice work Patrick. Who wants to CEPify it? Let's go ahead and put it up. -Jackson > > Once we add the CEP template and do a couple other things to the > theme... I think it's a respectable new look for phpenterprise.net > > Thoughts? > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Cep-development mailing list > Cep...@li... > https://lists.sourceforge.net/lists/listinfo/cep-development |
|
From: Marcus W. <ma...@ph...> - 2004-12-09 19:31:09
|
Jackson Miller wrote: > Ok, I have a fresh cep install on PHP5 up at http://cep.jaxn.org. nice > > Auth doesn't work. I don't know why, though I dug into it for a while > last night. maybe... crappy implementation :) > > I looked at LiveUser too, but... > > I think we should go back to handling it all on our own. I think I am > going to overhaul auth and permissions (it needed it anyway). I am > going to keep all the functionality, but I am going to make it more > object oriented and cache a user object in the session. We can make > the user object configurable ala LocalClasses or something so that > people can use Auth if they want (or LiveUser or OCI, etc). I am > thinking something along the following: Interesting. This is probably wise. These two packages have lots of functionality, but the way they are designed is not ideal. > > CEP_User::doLogin($username, $password); > CEP_User::isAuthenticated(); // may be redundant > CEP_User::getUserID(); > CEP_User::checkGroup($group); > CEP_User::checkPerm($cep_object_id,$level); > CEP_User::doLogout(); > > We can add session hijacking protection later. yup. > It should be pretty easy to retrofit another auth/perm package to work > behind this interface, but I say we just ship our own implementation. > It is important that we control the API for our modules/libraries to > have access. > Also, by putting the CEP_User object in the session, it persists > across requests, reduces the overhead of object creation (object only > created once per session), and gives global access. agreed. Can we get some requirements of the auth package/CEP_User object down before we lockdown the API? Even if the above meets what the requirements end up being? > > -Jackson > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Cep-development mailing list > Cep...@li... > https://lists.sourceforge.net/lists/listinfo/cep-development |
|
From: Jackson M. <jm...@ma...> - 2004-12-09 17:23:54
|
Ok, I have a fresh cep install on PHP5 up at http://cep.jaxn.org. Auth doesn't work. I don't know why, though I dug into it for a while last night. I looked at LiveUser too, but... I think we should go back to handling it all on our own. I think I am going to overhaul auth and permissions (it needed it anyway). I am going to keep all the functionality, but I am going to make it more object oriented and cache a user object in the session. We can make the user object configurable ala LocalClasses or something so that people can use Auth if they want (or LiveUser or OCI, etc). I am thinking something along the following: CEP_User::doLogin($username, $password); CEP_User::isAuthenticated(); // may be redundant CEP_User::getUserID(); CEP_User::checkGroup($group); CEP_User::checkPerm($cep_object_id,$level); CEP_User::doLogout(); We can add session hijacking protection later. It should be pretty easy to retrofit another auth/perm package to work behind this interface, but I say we just ship our own implementation. It is important that we control the API for our modules/libraries to have access. Also, by putting the CEP_User object in the session, it persists across requests, reduces the overhead of object creation (object only created once per session), and gives global access. -Jackson |
|
From: Jackson M. <ja...@ph...> - 2004-12-08 21:36:35
|
I migrated my store's website to the CEP 1.0 alpha3 release today. It is running on PHP5 and everything is working. I do think there is some kind of problem with PEAR::Auth or our use of it, but I thought I would let everyone know http://platostn.com is running CEP on PHP5. Also, I am re-exploring the idea of CLAMs in CEP. Since I think we are going to move forward with this I thought I would propose some definitions: CLAMs - Components, Libraries, Aspects, Modules Components - Reusable pieces of interface (typically HTML based user interface, but always client interface whether it is HTML, web services, CLI, daemon, etc) Libraries - Task-based implementations of business rules Aspects - Cross-cutting concerns ala AOP Modules - Modules are reusable combinations of libraries and components. I hope that modules will include event-handlers. -Jackson |
