Welcome to Rainbow Portal Community Sign in | Join | Help

Rainbow Core API Thoghts

Lately we have been doing a lot of talking about what can be done with the core, what is being done, and what will happen.

One of the more interesting discussions for me going on right now, is the talk of api's for rainbow.

  • Application API - Thing of it as framework or System
    • Allot of core business logic
    • Services that content, modules, controls all need to use
    • Permission API
      • Manage the permissions for everything separate from itself, ill get into this later.
    • Pages API
      • Site Map
      • Google Site Map Generator
      • Page Business Logic
      • Content API
      • Membership & Profile API
      •   Namespaces then would look something like

          • Rainbow
          • Rainbow.Application
          • Rainbow.Site
          • Rainbow.Pages
          • Rainbow.Security
          • Rainbow.Security.Permissions
          • Rainbow.Users
          • Rainbow.Content
          • Rainbow.Web
          • Rainbow.Web.UI
          • etc......
          • The logic then being that allot of the code gets abstracted, becoming more scalable, maintainable and easy for devs to implement and use.

            So if you where to create a new module, or control, or web part, or whatever you want to call it... you could do nifty things like this.

               1:  Rainbow.Content.Module.Install();
               2:  Rainbow.Content.InsertItem();
               3:  Rainbow.Content[itemID] = your item;
               4:  Rainbow.Content.ContentItem.ChildItems[3].FullText = FCKEditor.Text;
               5:  DateTime dateCreated = ContentItem.ChildItems[3].DatePublished;

            Of course, the Object ContentItem would make use of the permission api.

            So the content Item would be smart and work in conjunction with the current requests user... so you might end up with something like

               1:              User curUser = rainbowpage.currentuser;
               2:              if(curUser.HasUpdate(contentItemId))
               3:              {
               4:                  ContentItem _item = new ContentItem(contentItemId);
               5:                  _item.FullText = "";
               6:                  _item.Author = "";
               7:                  _item.LastUpdated = DateTime.Now; // should be inside the API
               8:                  business logic :-)
               9:                  _item.Save();
              10:              }

            Anyway, we have some time till we actually start seeing stuff like this, however, it's nice to think about and start considering the design of such APIs, also I was bored and felt like adding ann entry into my blog.

            - Jonathan F. Minond

Published mercoledì 8 febbraio 2006 19.46 by Jonathan


# re: Just some thinking

giovedì 9 febbraio 2006 1.17 by ramseur
hopefully the Membership API will be all we need for users. However there will still have to be an internal Rainbow User API for representation of rainbow internal things like module security/portal security.

# re: Just some thinking

giovedì 9 febbraio 2006 17.18 by Jonathan
I would like the membership api to house all user info... however security, i want moved to the permission api...... as the security is part of RB.

So on the BLL Layer, when requesting / fetching data, the core will know the user and his roles, and only request from or update to the dal data which the user is permissioned for.
The permission api will manage permssion for the applicaion, sites, pages, and content.
Anonymous comments are disabled