Hi Rob at al
I understood what you mean by having just the UI separated from the rest of
the code base so that users can have a crack with it using VS2005 Web
Developer Express. I have actually friends here (who doesn't know any sorts
of coding other than CSS and HTML), they are asking a web interface where
they can easily change the layout, save it and go.
At the moment those ascx files under each skin folder is just a space
consumption. It gives more flexibility but harder to deal with for those who
don't know what to do with them. I think what you are saying is a good point
as a starting point to make it easy for novice users.
If we separate the engine, others can probably use it to create something
else out of it which I think is a god thing for an open source project.
Gurkan Yeniceri
http://www.analystdeveloper.com <http://www.analystdeveloper.com/>
Blog: http://blogs.analystdeveloper.com/gurkaneng
Tel: 0408 45 88 33
MSN: gyeniceri AT hotmail dot com
_____
From: subtext-devs-admin@...
[mailto:subtext-devs-admin@...] On Behalf Of Robb Allen
Sent: Friday, 28 April 2006 12:57 AM
To: subtext-devs@...
Subject: Re: [Subtext-devs] 2.0 thoughts
On Roles - The number of roles from the start is irrelevant from the
programming aspect, what is important are all the things that a role can
actually do. At work we call them 'Activities'. I think WordPress calls them
'Capabilities'.In Windows they're referred to as 'User Rights'. These are
the individual system functions that are secured by a role. Once you have
them all defined, roles are nothing more than different combinations of
them. So starting with only a few roles defined is fine by me - additional
roles would be data driven and would not require code changes. Just have to
make sure we've got all the (Activities / Capabilities / User Rights)
defined first.
On Ground-Up - At work, all my web projects at work are nothing more than
UI's that consume business objects. Even though this kind of defeats the
purpose of a blog, conceptually we should be able to run the whole thing
command line. Right now, Subtext requires a UI in order to compile
(Subtext.Web). Now, this is only my opinion and you know how I pull things
out of my rear so don't take this as how I'm sold on the approach, but I'm
willing to bet that most people who use Subtext are only going to change the
UI. It would be nice if people could just download the VS 2005 Web Express
and fiddle fart with just the UI without having to worry about recompiling
the Framework classes (and vice versa). It's a gut feeling more than a well
documented and thought out concept.
So, to make a ridiculously long story not quite as long - Maybe not a
complete, ground up redesign, but segregate whatever other classes need of
Subtext.Web into it's own project and allow the UI to be just that. Then
have two completely separate projects - UI & Engine.
I'm probably not being clear on this. I'm a shitty writer. Let me know how
confusing I'm being and I'll try to clarify (if possible ;)
R
Phil Haack wrote:
I really need to get that wiki module set up. I'll try and do that this
weekend.
1. Yes.
2. What do you mean? A re-write of Subtext.Web? In general, I like to
avoid ground-up. I'd prefer to refactor/refactor/refactor. Unless given a
really compelling reason.
3. I personally would like to tackle security in two phases
(corresponding to two releases). I would venture that 99% of our users
stick to single blog installations. Most users only really need one role,
"Admin". I think in phase 1, we should keep things really simple and do the
following:
a. Phase 1
i.
Decouple users from the blog (i.e. remove the username and password from
subtext_config and into its own membership provider table).
ii. Add
two roles
1. Admin (rights to the admin section for a specific blog)
2. HostAdmin (rights to the HostAdmin section)
iii. Make
sure this integrates using Membership and provider
b. Phase 2
i.
Either add more roles pertaining to activities, or add the concept of
permissions.
4. Please do flesh this out. I do like the idea of separating out
skins that come with Subtext and user modifications. We always want to look
at clearly delineating the boundary between user mods and Subtext core.
5. We have a database provider. We would just need to build new
providers. Right now, I don't think we need a separate provider for SQL
Server 2005 or SQL Server 2005 express. It'll probably just work with the
existing provider.
6. Yes.
7. Yes.
Regarding #3. I'm open to suggestions, but I really think we should start
simple as to meet the needs of the majority. And then in a subsequent
release, iterate on it and fine tune the security model. We might consider
a 3rd role (subscriber) for the first release. I know some blogs take that
approach.
Phil
_____
From: subtext-devs-admin@...
[mailto:subtext-devs-admin@...] On Behalf Of Robb Allen
Sent: Wednesday, April 26, 2006 3:22 PM
To: subText Mailing List
Subject: [Subtext-devs] 2.0 thoughts
Yes, I'm chomping at the bit to get started, so just throwing a few things
out there for discussion
1. Are we going to move towards the MasterPage concept with Themes for
skinning? Using MasterPages really opens up allowing fine grain, programatic
control over skins. Themes, of course, are an easy way to develop new skins
without worrying about every little control.
2. What are the thoughts on a ground up approach to the Subtext.Web
portion? A lot of work, yes, but I think it would make for a better product
in the long run. Just a crazy thought, feel free to tell me to go pound
sand.
3. For security, we'll need to get a list together of activities that
can be performed in the blog so that roles can be developed to encapsulate
them (things like "Add Post", "Add Comment", "Delete Blog", "Edit User
Info", etc. I have a draft email I'm working on to lay out as many of these
as I can think of, so wait for that to start the conversation.
4. Back to skins, I've got a few ideas on how to have custom,
local-to-the-blog skins as well as global skins. I'll flesh this idea out as
well, but I'd like to hear all the issues everyone has thought of / come
across in having multiple skins.
5. Database provider - Both SQLServer 2005 and 2003? With 2005, using
the file based one with everything premade would rock. But not everyone will
support it, so the provider would allow the flexibility.
6. Back to skins again, as a few posts popped up earlier, we should
look at some sort of mechanism for personal image storage & retrieval, as
well as global.
7. Installation - 2.0 has a pretty nifty Wizard system. Might make that
a little easier.
Anyway, just a quick laundry list of things on my mind. Feel free to add,
subtract, or divide as you wish.
R
------------------------------------------------------- Using Tomcat but
need to do more? Need to support web services, security? Get stuff done
quickly with pre-integrated technology to make your job easier Download IBM
WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk
<http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642>
&kid=120709&bid=263057&dat=121642
_______________________________________________ Subtext-devs mailing list
Subtext-devs@...
https://lists.sourceforge.net/lists/listinfo/subtext-devs
------------------------------------------------------- Using Tomcat but
need to do more? Need to support web services, security? Get stuff done
quickly with pre-integrated technology to make your job easier Download IBM
WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ Subtext-devs mailing list
Subtext-devs@...
https://lists.sourceforge.net/lists/listinfo/subtext-devs
|