SitePoint Sponsor |
|
User Tag List
Results 26 to 50 of 325
-
Sep 12, 2005, 14:39 #26
- Join Date
- Aug 2003
- Location
- Toronto
- Posts
- 300
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
FWIW, I think that the template patterns are deceptively simple but in fact are rather complicated to generalize mainly because there are so many ways to approach them. Perhaps it might be more productive in terms of this thread to start with a smaller, more narrowly defined concept. For example, cache access, resources/libraries, parsers, etc.
There seems also to be some issue in the thread about implementations following the interface (ie. needing to be re-written to the "standard"). This ought not be strictly so: emulation through adaptors should be sufficient.
-
Sep 12, 2005, 14:50 #27
- Join Date
- Sep 2003
- Location
- Wixom, Michigan
- Posts
- 591
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I agree with you, jayboots. I think the idea of adaptors is a key one here. Maybe the best chance this has of becoming the standard it needs to be is by being more of a repository of adaptors rather than interfaces only. That way if someone wants to submit a class for "compliance" they wouldnt need to rewrite their interface (fat chance this would happen in the majority of cases), but rather simply just provide an adaptor that couples with the standard interface, and the same level of interoperability could be achieved.
Garcia
-
Sep 12, 2005, 15:02 #28
- Join Date
- Aug 2004
- Location
- California
- Posts
- 1,672
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Travis S
Originally Posted by Travis S
Originally Posted by Travis S
Originally Posted by Travis S
If you can get that group (throw in lastcraft too) to agree on an interface I will start using it. In fact I would help work to reimplement the Skeleton using these "standard" interfaces as a test bed.
So lead the process Travis, you said we need a DataSpace before we can define a Template. Start there and see how it goes. (sound of Champagne bottle crashing on Travis' bow .... splash!)Christopher
-
Sep 12, 2005, 15:21 #29
- Join Date
- Aug 2003
- Location
- Toronto
- Posts
- 300
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
ghurtado, I like your thinking. I wonder if it would be equally suitable to have a related secondary project that strictly dealt with adaptors. Adaptors can be rather tricky in their own right since they are so dependant on implementation. As such, I see them as having a lower "standardization" quotient (to make up new terms) than interfaces. Separating the two, the interfaces project could stay more on goal but would have some impetus to consider the needs of adaptor classes. At any-rate, I suspect that without adaptors for popular libraries, buy-in will be much harder to foster.
-
Sep 12, 2005, 15:37 #30
- Join Date
- Sep 2003
- Location
- Wixom, Michigan
- Posts
- 591
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Maybe the standards project could provide two different "levels" of approval? One for compliant interfaces and another one for libraries with compliant adaptors. But at the same time, it wouldn't be a good idea to "downgrade" those that achieve compliance via adaptors instead of interfaces. I think they could be the majority anyway. So the first step is defining the interfaces anyway, and then it is the developers choice to provide interface compliance or adaptor compliance.
If the whole adaptor idea takes off, I see a lot of potential for this project. May we want to start with some coding guidelines / best practices, perhaps?Garcia
-
Sep 12, 2005, 15:59 #31
- Join Date
- Nov 2002
- Posts
- 841
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by arborint
There would be real benefit to having a standard component model for PHP.
-
Sep 12, 2005, 16:41 #32
- Join Date
- Aug 2004
- Location
- California
- Posts
- 1,672
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Selkirk
Christopher
-
Sep 12, 2005, 16:59 #33
- Join Date
- Jun 2004
- Location
- Copenhagen, Denmark
- Posts
- 6,157
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
It's probably a good idea to accompany each interface with appropriate adapters to known (and popular) implementations. I have the feeling that this would by far exceed the interfaces themselves in size, but that's not bad. In fact it could result in a general integration/compatibility toolkit for all the disparate libraries around. That would definately be useful.
-
Sep 12, 2005, 17:16 #34
- Join Date
- Oct 2004
- Location
- Kansas City, MO
- Posts
- 68
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I'm on board... I would say let's work with the type of data object you would see as part of a Data Mapper (i.e., a smart/settable Value Object).
First thing, each object needs to have a means of saying what it contains. We could use the line that ItemForSale->getAmount() will always get that item's "amount" value, or it could be ItemForSale->get('amount'). The latter leads to easier swaping between objects because there's no need to tie to a specific method.
With either, there needs to be a means of introspection so outside code knows what is available (I'm thinking particularly the Mapper part of DataMapper in this case). Something along the lines of getAvailableProperties() or getDeclaredProperties()?
Of course, I do have to interject phpCR here again. It abstracts this out by having each node (dataobject, datasource, etc.) have a primary node type. The node type can contain any number of property and child-node definitions that define how things behave under it. I am currently working on a concrete implementation of this where the node type is the table name, and the property definitions are based on the table definition.
As far as the recent discussion of adapters - that is something that would really be best left to the individual packages themselves. Say we come up with a Template interface and someone wanted to create a Smarty or Savant adapter to it, that would be great, but I think energy would initially be better spent working out the abstract interfaces instead of working out concrete adapters. Although maybe that could be used as a sort of "testing ground" - the interface should be abstract enough that it could be strapped onto any existing API without too much hassle until the code can be refractored to match the real interface.
I think there should be an Adapter interface. I would leave it completely blank, just to serve as a means of identifying that you're dealing with an adapter instead of straight code.
Originally Posted by ghurtado
I would favor hard tabs to soft - even though PEAR does it the other way - simply from a storage perspective. "\t" is faster to load and smaller to storage than " ".
What else am I leaving out?
-
Sep 12, 2005, 18:22 #35
- Join Date
- Aug 2004
- Location
- California
- Posts
- 1,672
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Travis S
Christopher
-
Sep 12, 2005, 19:03 #36
- Join Date
- Nov 2002
- Posts
- 841
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Game On!
First thing, each object needs to have a means of saying what it contains. We could use the line that ItemForSale->getAmount() will always get that item's "amount" value, or it could be ItemForSale->get('amount'). The latter leads to easier swaping between objects because there's no need to tie to a specific method.
PHP Code:Interface DataSource {
function __get($property);
function __set($property, $value);
function __isset($property);
function __unset($property);
}
PHP Code:class MyDatabaseConfiguration extends DataSourceSupport implements DataSource {
public $host = 'localhost';
public $database = 'myapp';
public $user = 'jeff';
public $password = 'secret';
}
With either, there needs to be a means of introspection so outside code knows what is available (I'm thinking particularly the Mapper part of DataMapper in this case). Something along the lines of getAvailableProperties() or getDeclaredProperties()?
PHP Code:interface PropertyInfo {
function getName();
}
interface DataSourceInfo {
function getClass();
function getPropertyInfo($property);
}
Now, there are three kinds of properties: standard, read only and write only. So
PHP Code:interface PropertyInfo {
function getName();
function isReadable();
function isWritable();
}
PHP Code:class PropertyNotFoundException extends Exception {}
PHP Code:interface DataSourceInfo {
function getClass();
function getPropertyInfo($property);
function canAddProperties();
}
PHP Code:interface DataSourceInfo {
function getClass();
function getPropertyInfo($property);
function canAddProperties();
function canRemoveProperties();
}
PHP Code:class CannotRemovePropertyException extends Exception {}
PHP Code:Interface DataSource {
function __get($property);
function __set($property, $value);
function __isset($property);
function __unset($property);
function hasProperty($property);
function addProperty($property, $value);
function removeAllProperties();
function setMany($propertyValueList);
function import($propertyValueList);
}
I would favor hard tabs to soft - even though PEAR does it the other way - simply from a storage perspective. "\t" is faster to load and smaller to storage than " ".
(I don't use php 5 oo on an everyday basis please correct and forgive any transgressions I may make)
-
Sep 12, 2005, 19:58 #37
- Join Date
- Oct 2004
- Location
- Kansas City, MO
- Posts
- 68
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by arborint
When I look at that, I would make it one simplier - it's an aggregate/registry of Value Objects. Going back to the Node/Property paradigm, the DataSpace would be the node and the Value Objects would be the properties. To me, the node/property phrasing seems to work well probably because I've seen it so much.
I've just given a quick glance at the WACT DataSpace code - it actually looks a lot like a Session in JCR - an aggregate of available items. Trying to back that out to the least common denominator, I see the Value Object/Property. It needs to be able to hold any type of native of PHP variable.
PHP Code:// just some ideas...
interface ValueObject {
public function getName();
public function getValue();
public function getType();
}
interface MutableValueObject extends ValueObject {
public function setValue($value);
}
// Decorators
interface MorphingValueObject {
// Original decorated
public function getName();
public function getValue();
public function getType();
// base types - where conversion is possible (getType() != array || object)
public function getString();
public function getInteger();
public function getFloat();
public function getBoolean();
// special cases - these throw exceptions except on getType() == array || object
public function getObject();
public function getArray();
}
interface MagicValueObject {
public function getName();
public function getValue();
public function getType();
public function __get($key);
// no action is taken unless decorating a MutableValueObject
public function __set($key, $value);
}
Quick note... All Exceptions should extend from RuntimeException which is being introduced in PHP 5.1. Until then, you can do a check to see if it exists and define it as a straight extends Exception. RuntimeException doesn't add anything to Exception, just helps denote that it happened during the course of excution.
Jumping to the final interface:
PHP Code:Interface DataSource {
function __get($property);
function __set($property, $value);
function __isset($property);
function __unset($property);
function hasProperty($property);
function addProperty($property, $value);
function removeAllProperties();
function setMany($propertyValueList);
function import($propertyValueList);
}
PHP Code:function import($propertyValueList[, $onCollisionAction]);
class Action
{
const OVERWRITE;
const IGNORE;
const MERGE;
const EXCEPTION;
// more?
}
PHP Code:interface DataSource
{
public function getProperty($propertyName);
public function setProperty(Property $property);
public function hasProperty($propertyName);
public function hasProperties(); // i.e. isEmpty()
}
interface MagicDataSource extends DataSource
{
// $key included for PHP internal use, but should almost always == $value->getName()
public function __set($key, Property $value);
public function __get($propertyName);
}
interface DataSourceFactory {
/**
* @returns DataSource
*/
public function import($values);
}
For the the sake of those who haven't looked at it and don't know anything about it. Here's the quick tour. phpCR is a repository made up of items. All of the items are broken down into two sub-types, nodes (or branches) and properties (or leaves). Using this forum as an example, the node is this post, while my name as poster, the time I post, the content I post, etc., are the properties that belong to it. Beyond that, there's the relation between the nodes, mechanisms for saving, etc., but that's the basics.
Again, for the benefit of people who haven't seen it, here's a copy of the interfaces with all the docblocks stripped.
PHP Code:interface Item
{
public function getPath();
public function getName();
public function getAncestor($degree);
public function getParent();
public function getDepth();
// Session refers to the container
public function getSession();
public function isNode();
public function isNew();
public function isModified();
public function isSame(Item $otherItem);
public function accept(ItemVisitor $visitor);
public function save();
public function refresh($keepChanges);
public function remove();
}
interface Node extends Item
{
public function addNode($relPath, $primaryNodeTypeName = null);
// This is a method I'd happily drop - I haven't found a good use for it yet
public function orderBefore($srcChildRelPath, $destChildRelPath);
public function setProperty($name, $value, $type = null);
public function getNode($relPath);
public function getNodes($namePattern = null);
public function getProperty($relPath);
public function getProperties($namePattern = null);
public function getPrimaryItem();
public function getUUID();
public function getIndex();
public function getReferences();
public function hasNode($relPath);
public function hasProperty($relPath);
public function hasNodes();
public function hasProperties();
// mixin = additional node type definitions to add restrictions, behavior
// PrimaryNodeTypes specify concrete behavior. Example: the presence of
// mix:versionable means this node can be versioned, while nt:file means
// this node represents a file. (both pulled from JCR spec, but neither
// required).
public function getPrimaryNodeType();
public function getMixinNodeTypes();
public function isNodeType($nodeTypeName);
public function addMixin($mixinName);
public function removeMixin($mixinName);
public function canAddMixin($mixinName);
public function getDefinition();
// Optional Level 2 functionality
public function checkin();
public function checkout();
public function doneMerge(Version $version);
public function cancelMerge(Version $version);
public function update($scrWorkspaceName);
public function merge($srcWorkspace, $bestEffort);
public function getCorrespondingNodePath($workspaceName);
public function isCheckedOut();
public function restore($versionName, $removeExisting, $relPath = '');
public function restoreByLabel($versionLabel, $removeExisting);
public function getVersionHistory();
public function getBaseVersion();
public function lock($isDeep, $isSessionScoped);
public function getLock();
public function unlock();
public function holdsLock();
public function isLocked();
}
// Several of these are only in here because they existed in the original
// Java source. I would say we could drop getLong()/Double/Stream/Date
// without much hassle. I would like to see getDate() brought back though
// if PHP ever has a native Date object.
interface Property extends Item
{
public function setValue($value);
public function getValue();
public function getValues();
public function getString();
public function getFloat();
public function getDouble();
public function getStream();
public function getDate();
public function getBoolean();
public function getInt();
public function getLong();
public function getLength();
public function getDefinition();
public function getType();
}
-
Sep 12, 2005, 21:24 #38
- Join Date
- Nov 2002
- Posts
- 841
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Travis S
Also, I would abstract the property into the ValueObject I mentioned above. That makes DataSource a container of Properties/ValueObjects and simplifies DataSource's API.
setMany()/import() seem too similar in name and I'm afraid would end up being mixed up. I would remove setMany() and give its role to import(). import() also needs a means of handling naming collisions:
PHP Code:function import($propertyValueList[, $onCollisionAction]);
class Action
{
const OVERWRITE;
const IGNORE;
const MERGE;
const EXCEPTION;
// more?
}
I also prefer not to use constant parameters. When I see this, I usually refactor to
importOVERWRITE()
importIGNORE()
importMERGE()
importEXCEPTION()
and then start to try to think of better names. Which would probably put us back at import and setMany.
I can also tell you from experience that some implementations will want to override setMany with a different implementation and some will want to override import with a different implementation. Having the constant parameter makes this more complicated because the subclasses also have to have a case statement for the constant. I usually try to avoid case statements based on constants in OO code. I have an old post describing my attitude on this issue that actually nearly uses this very example.
Regarding collisions, i don't see them. SetMany is conceptually equivalent to a series of __set calls.
PHP Code:$ds->setMany(array('A'=>1, 'B'=>2));
// Same as
$ds->__set('A', 1);
$ds->__set('B', 2);
// Same as
$ds->A = 1;
$ds->B = 2;
In which case I would be included to say the last value wins.
Conceptually, import is equivalent to, um, well, thats hard to explain exactly and thats a problem.
Personally, these are both just convenience methods. I just did a grep of my own WACT based code and I don't use either methods in any current code. There may be some WACT users with a different style of coding, however, that do rely on these methods.
I'll withdraw the setMany and import methods as unnecessary.
-
Sep 12, 2005, 22:01 #39
- Join Date
- Mar 2005
- Posts
- 53
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Hello everyone,
As always, I'm following another great thread with much enthusiasm (a nod to the people from the application controller thread and the skeleton thread). As of late, I've assumed command of creative direction in the Mojavi PHP Framework. Prior to being given control of direction, I was designing, for a number of weeks, a branch of Mojavi 3.0.0-DEV, whose UML diagrams can be found on the mojavi forum. Information on this branch can also be found on the forum at this thread.
However, my pupose for posting here is not to introduce any of you to Mojavi, but rather to introduce the diagrams. For a long while now, I've wanted to create, in some manner or another, a series of interfaces/concrete classes which would be designed well enough (through either dependency injection, or another less un-intrusive technique) to competely unplug from the framework and share with other projects. However, this sort of vision usually falls short of any sort of realization due to the many very palpable problems and mistakes taken in this direction in the past (namely PEAR).
What I would like to suggest is that this group take a look at my designs, give feedback, and I will do likewise. I would like to, if possible, stay away from Controller layer constructs simply because of their very MVC-ish nature (if someone has reason to present Controller-layer interface suggestions I would certainly be open to it).
Now, off the topic of the diagrams, and for some feedback for you guys:
The datasource implementation through a node/container pattern seems much cleaner to me. Since the datasource is already being abstracted, why not go a bit further to:
PHP Code:$obj->getAttrContainer()->get('val');
One last thing just for references:
Renderer => Template
Container et al. => Dataspace
I look forward to your responses,
Regards,
Tyler
-
Sep 12, 2005, 22:19 #40
- Join Date
- Oct 2004
- Location
- Kansas City, MO
- Posts
- 68
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Selkirk
Completely off-topic - when will SF ever get around to implementing SVN? I'm tired of having to look up CVS commands
Originally Posted by Selkirk
This is actually an area where the Node/Property relation in phpCR needs some investigation. I'm working out from an implementation standpoint whether it should be on par with a Node as an entry in an Items table and just attach some sort of storage to it for its value (i.e. Item's existance is in Items table but its actual string value is in StringProperties), or whether it should exist virtually as a column in a table, or...?
Originally Posted by Selkirk
Originally Posted by Selkirk
Alright!We've got our another framework guy pitching in... This is the direction I wanted to go in... getting everyone (well, at least a good sized portion of "everyone") on board and coming up with some standards that everybody can live with.
First off, I like the UML - nice work. I actually should put something together like that for phpCR. I think if people saw it diagrammed they wouldn't flinch as much as looking at the code, API docs, or 200+ spec sheet from the Java version.
Second - the exceptions. I agree. I did some testing on assert() versus using home grown methods a fews weeks back (the full article is here). The results when comparing a simple my_assert() that did an if(!$value) { trigger_error() } floored me. Definitely, whenever we can I would say use built in features...
Now, to come back to your actual code ideas. phpCR uses the overall container of "Session" - a name I don't like because of the class with the concept of "sessions" in PHP, but used as I wanted to do a straight port to start with. From the Session, you can grab any number of nodes - or containers of properties in this context. In an ideal world, such an interface could serve as the basis for a Model which could then be interchanged between Mojavi, WACT, Solar, or any other system. If all three were implementing the same content repository/model API, you could then take your data from any system and drop it into the controller/view of another system.
I guess this really depends on one thing though. Do we want the Datasource/Container to be able represent data in the database and serve as a crude model, or are we after a fancy array?
Tomorrow in the morning I'll work up some basic UML diagrams of the core functionality inside phpCR and strip out all the extras. As I posted the full interfaces earlier, I realized there was actually a lot of room for decorator use there and I'm not sure why it wasn't used in the Java version. It could give you an instance clue as to whether your Node is lockable if your Session->getItem() returns LockableNode and its much more intuitive than having lock() throw an unsupported repository exception.
Anyway... manana...
-T
-
Sep 12, 2005, 22:42 #41
- Join Date
- Oct 2004
- Location
- Kansas City, MO
- Posts
- 68
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by myself...
Here you go...
A lot of the parameter naming would probably make sense to revisit - this is just the way it is right now. Session in particular has been cut way down, and I've pulled a lot of the superficial out of Node.
-
Sep 12, 2005, 23:59 #42
- Join Date
- May 2005
- Posts
- 255
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by ghurtado
I actually saw code a few weeks ago with this implementation (replaced the prefix with "x" so as to not identify the guilty party).
PHP Code:class xString{
function __toString()
{
...
}
}
-
Sep 13, 2005, 00:37 #43
- Join Date
- Aug 2004
- Location
- California
- Posts
- 1,672
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
A thread with Selkirk and illusina tentatively discussing a common set of interfaces on which to build PHP frameworks? Has the world gone mad!
From looking a code and diagrams there appears to be a lot of common ground here. I like that Selkirk is already ditching crufty methods. Go, go, go.Christopher
-
Sep 13, 2005, 02:42 #44
- Join Date
- Jun 2004
- Location
- Copenhagen, Denmark
- Posts
- 6,157
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Travis S
I haven't consumed all of thoose lengthy posts just yet, but I have one though about the interface of DataSource/DataSpace/Node/ValueObject. The implementations discussed so far, imply a flat collection of properties (like properties of an object). A basic ArrayDataSpace would map theese to keys in an underlying array. What happens when this array is a jagged array - Eg. one of the properties is an array ? Should the DataSpace then return the array, or should it return a new ArrayDataSpace wrapper around it ? Also - how intelligent should such a DataSpace be ? Should it be possible to select with an xpath-like query, into a subnode ? Perhaps we should operate with two interfaces - a base IDataSpace and an extended IHierarichalDataSpace ?
-
Sep 13, 2005, 05:00 #45
- Join Date
- Jan 2003
- Posts
- 5,748
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Yes, interesting discussion and I'm looking forwards to reading more, so please continue
Should the DataSpace then return the array, or should it return a new ArrayDataSpace wrapper around it ?
In that regards, shouldn't the client script make the choice in how to handle or manage the array. Giving the data source/data space the role of returning a new data source/data space object is not part and parcel of the responsibilities, from my perspective that is.
-
Sep 13, 2005, 05:06 #46
- Join Date
- Jun 2004
- Location
- Copenhagen, Denmark
- Posts
- 6,157
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
OK. I had this idea cooking in my cranium since yesterday. Sorry if it's diverting the current topic of formulating a common DataSpace interface.
A short explanation :
As arborint nicely demonstrated, and most of us realize, defining a common interface between two analog (at least to some degree) implementations is only part of the problem. The real challenge is how to get the implementations to actually conform to the interface. The answer is ofcourse to provide wrappers, which made me think about a framework for doing this.
The basic structure is somewhat inspired by the interface of XPCOM - class/method naming is mostly random. For one thing, I don't know if ComponentLocator is very descriptive.
Without further ado.
-
Sep 13, 2005, 06:11 #47
- Join Date
- Jan 2004
- Location
- 3rd rock from the sun
- Posts
- 1,005
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I also think a big reason it won't work is that the vast majority of PHP programmers, didn't start as programmers, and aren't really interested in standards, just "making it work".
The value of standards is very, very high on the priorities of anyone who has done anything on the web over the last 5 years... tag wars et al, if(document.layers)... remember all that crap?
Possibly because of PHP's lower barrier to entry...?
Who is this library aimed at, define the target audience and what they will ideally want from it. If that doesn't include "scripters learning to be programmers" then you can easily forget about lower barriers to entry.
To build upon Travis S's point
Determine the scope..
-
Sep 13, 2005, 07:03 #48
- Join Date
- Oct 2004
- Location
- Kansas City, MO
- Posts
- 68
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by kyberfabrikken
PHP Code:$qm = $node->getSession()->getWorkspace()->getQueryManager();
$query = $qm->createQuery('/path/to/node', 'xpath');
$result = $query->execute();
Originally Posted by Dr Livingston
PHP Code:$property = $node->setProperty('array', array(1, 2, 3));
$array = $property->getValues();
One thing I'm curious about - what is everybody else's thought on the Property interface in the context of the diagram above? Is it redundant? The one benefit I see with it is the ability to transform a value that's pulled out of storage into something more usable, but seeing as how PHP is loosely-typed, maybe that kind of cleverness is best left up to the final implementors?
Originally Posted by paulyg
All that said, if we can build the simplest solution and slowly add layers to it through decoration and/or inheritence, then maybe the casual scripter can start at the simplest level and implement more and more as they become more proficient.
-
Sep 13, 2005, 07:58 #49
- Join Date
- Jan 2003
- Posts
- 5,748
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
the Session is your user's current view of the repository within his given Workspace.
If they could have one or more, then wouldn't this allow for increased flexibility for the actual application developer (not the framework developer), where the user is doing one task, and then off they go, and do another different task altogether at the drop of the hat, and to come back later to the original task.
I'm asking, as I don't know if you at the moment allow for more than the one workspace you see.
-
Sep 13, 2005, 08:15 #50
- Join Date
- Oct 2004
- Location
- Kansas City, MO
- Posts
- 68
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Dr Livingston
As far as how many a user can get - theoritically, a user could go back to Repository and ask for any number of workspaces using the same credentials (unless you implement some sort of expiration on the Credentials). That said, I'm not sure I see how multiple would be useful, unless of course you're loading all of the values into _SESSION and not closing them until the user executes a save.
As far as conceptual view of what the Workspace is - I've always viewed it as a view of the repository. That might not be correct in terms of JCR, but that's how I've viewed it. That, and any actions it takes are always followed by save() internally
Bookmarks