Mailing List Archive

David,

The current revision seems ok for us at current time.

As for the best way to handle related assets, my guess is that $burner
should make this issue as transparent to the template developer as
possible, which would allow easy aliasing of stories between sites,
while allowing story edition and relation in the same category without
too many template mess.



That question also raised one point: In the site field,
it'll probably be nice to be able to select the preferred protocol
for the site, whether 'http', https or something else, so that
you don't have to hardcode

$domain = 'http://' . $relstory->get_site->get_domain_name;
but instead,

$domain = $relstory->get_site->get_protocol .
$relstory->get_site->get_domain_name;

or even having a URI(3) object loaded with the site's values for url
handling.

I'd also like to point out how MultiSite will bring a bigger emphasis on
sub-elements. Since with Multisite all sub-elements are seen through all
sites, they must be quite well developed in the first place. Also,
current limits in editing sub-elements (editing a typo in an element
data field is a PITA), could cause installation-wide issues.

Just to show my concern on this, that would be solved once the elements
are redesigned.

Thank's, have a nice weekend!

JP



On Wed, 2003-02-19 at 21:06, David Wheeler wrote:
> Hi All,
>
> Well, I've done it again. I've made major revisions to the MultiSite
> functional spec. You'll find the latest here:
>
> http://bricolage.cc/docs/design/MultiSite/FunctionalSpec.html
>
> I've completely changed my approach to managing stories and media in
> sites. They now can be associated with only one site, but now users can
> create new "alias stories" (or "alias media") that simply point to an
> asset to which they have READ permission. I think that this was
> originally Joao Pedro's idea, and on reflection, I thought it might be
> the best way to eliminate the permissions problems.
>
> Anyway, please read it when you have a chance. I'm going to start work
> on the technical spec tomorrow, but need to know from everyone:
>
> * What's wrong with this proposal.
> * What do you like?
> * What don't you like?
> * What's your response to the remaining question about related
> assets?
> * What am I missing?
>
> This last question is most important, as I'm sure that I must be
> forgetting things what with the size of the revision I'm proposing.
>
> Thanks!
>
> David
>
> --
> David Wheeler AIM: dwTheory
> david@kineticode.com ICQ: 15726394
> Yahoo!: dew7e
> Jabber: Theory@jabber.org
> Kineticode. Setting knowledge in motion.[sm]
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> The most comprehensive and flexible code editor you can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> Bricolage-General mailing list
> Bricolage-General@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bricolage-general
--
João Pedro Gonçalves
http://www.sapo.pt/ - Portugal Online



-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general

On Friday, February 21, 2003, at 11:58 AM, Joao Pedro Goncalves wrote:

> David,
>
> The current revision seems ok for us at current time.

I'm pleased that you find it satisfactory at the current time. ;-)

> As for the best way to handle related assets, my guess is that $burner
> should make this issue as transparent to the template developer as
> possible, which would allow easy aliasing of stories between sites,
> while allowing story edition and relation in the same category without
> too many template mess.

Yes, that's where I'm leaning, too -- with the proposal I've made for
the new burner method. Of course, template developers will then have to
be consistent in using the new interface for related asset URIs, or
they could end up with the wrong URIs. Making it easy will help -- and
it will be easier than it is now.

> That question also raised one point: In the site field,
> it'll probably be nice to be able to select the preferred protocol
> for the site, whether 'http', https or something else, so that
> you don't have to hardcode
>
> $domain = 'http://' . $relstory->get_site->get_domain_name;
> but instead,
>
> $domain = $relstory->get_site->get_protocol .
> $relstory->get_site->get_domain_name;
>
> or even having a URI(3) object loaded with the site's values for url
> handling.

Hrm. Wouldn't take much to add a default scheme (as URI(3) calls it).
I'll have to think about how to integrate a URI object. I do like that
idea, though -- I used URI objects to format URIs in the Macworld
templates.

> I'd also like to point out how MultiSite will bring a bigger emphasis
> on
> sub-elements. Since with Multisite all sub-elements are seen through
> all
> sites, they must be quite well developed in the first place. Also,
> current limits in editing sub-elements (editing a typo in an element
> data field is a PITA), could cause installation-wide issues.
>
> Just to show my concern on this, that would be solved once the elements
> are redesigned.

Yes, these issues will all be addressed in the element revision, which
I plan to get underway again next week.

Regards,

David

--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]



-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general

On Friday, February 21, 2003, at 02:02 PM, David Wheeler wrote:

> Hrm. Wouldn't take much to add a default scheme (as URI(3) calls it).
> I'll have to think about how to integrate a URI object. I do like that
> idea, though -- I used URI objects to format URIs in the Macworld
> templates.

Actually, now that I think about it, I think that the default
scheme/protocol should actually be a part of the output channel object.
I'll mention that in the technical spec.

David

--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]



-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general