Hi Dirksen,
I think the problem you are having has to do with using 'getItem'.
From the SkinScriptSyntax Wiki page:
"If the RESULT is NOT_FOUND, the search for the attribute value falls
through to the next declaration (or attribute provider if the SkinScript
is finished). If there is an
Hi Dirksen..
try this:
WITH Deliverables.getItem(self.id) COMPUTE name=((RESULT is _.None) and 'none
available') or RESULT.name
What are you using as the 'load by accessing attribute' attribute?
-steve
___
Zope maillist - [EMAIL PROTECTED]
Hi Steve,
It works! Thank you.
Still there's a couple of things to be cleared. What's the use of 'otherwise' clause?
And
is it true that the 1st 'with' clause fails, the whole skinscript process fails (so one
'with' clause is all one skinscript can put up with)?
Dirksen
Hi Dirksen,
OK.. the problem was that DataSkinAddons:DummyDataSkin doesn't
allow access to attributes of 'self'. Once I switched to a differnt
ZClass (which is a direct subclass of DataSkin) then everything
was fine again.. ) just for Facade instances:
I'm now using
WITH
Hi Dirksen,
For your 'otherwise' case, could you have a single instance
that serves as an 'unknown' object:
WITH Deliverables.getItem(self.id) COMPUTE
originalObject=RESULT or NOT_FOUND
OTHERWISE originalObject=Deliverables.getItem('Unknown')
where it is known that the Deliverables
Hi Dirksen,
Did you say you were using 0.4.3b1 or b2? I think that
this sounds like the bug from b1:
http://lists.zope.org/pipermail/zope-dev/2000-October/007650.html
-steve
"Dirksen" == Dirksen [EMAIL PROTECTED] writes:
Dirksen One more question, i.e. the following expression
Hi Steve,
I've made my experiment simple, by playing with the DumbZPatterns examples, testing one
rack under one specialist. Here is the skinscript:
WITH Deliverables.getItem(self.id) COMPUTE
name=name, dueDate=dueDate, description=description, todoIDs=todoIDs
WITH SELF COMPUTE
Hi Steve,
Deliverables has objects. The call to existent objects are successful. It's the call to
the inexistent objects that doesn't turn out expectedly. But the first thing is whether
my script is correct. Do you thing so? And any other way to test this kind of
situation,
i.e. passing
Hi Dirksen,
Ok.. you need to set the 'load by accessing attribute' field
to 'original_object'. You may need to change your SkinScript to
something like:
WITH getMale(self.id) COMPUTE original_object=(RESULT is _.None) and NOT_FOUND or
RESULT
So that when getMale returns _.None, the
Hi Steve,
Both racks are set to be loaded by accessing 'id', which, as you guessed right, don't
appear in handling attributes list!
This is the simplified skinscript in maleMemberRack:
WITH getMale(self.id) COMPUTE original_object=RESULT
WITH self.original_object COMPUTE
name=id,
I set up two racks in one specialist, one is maleMemberRack, the other
femaleMemberRack.
Both are loaded by accessing attribute id, and have skinscripts to retrieve data from a
db. Suppose the femaleMemberRack gets loaded first, it finds out from the db that the
'id' is a male, then how can it
Hi Dirksen,
Hmm... why not have the query that gets data qualify by gender:
SQL Query: getMemberByGender
parameters member_id, gender
select * from members where
dtml-sqltest member_id type=string and dtml-sqltest gender type=string
Then in the SkinScript for maleMemberRack:
WITH
Hi Dirksen,
Forgot to mention... you should probably choose some attribute other
than 'id' as the attribute to check for your DataSkin. The 'id' attribute
is always there...
-steve
"Steve" == Steve Spicklemire [EMAIL PROTECTED] writes:
Steve Hi Dirksen,
SteveHmm... why not
13 matches
Mail list logo
