DonationCoder.com Software > MEWLO Web Framework

OLD - Unfinished Web project: YUMPS

<< < (15/17) > >>

mouser:
I've started to work on the addon/plugin system for YUMPS (with events and triggers, etc.) .. Very fun stuff that I expect will evolve significantly over time.  But getting this right will be critical to making YUMPS useful.

mouser:
Rover actually mentioned the "Symfony2", and I've actually been giving some thought to whether Yumps might eventually benefit from a major rewrite to use the Symfony2 components, and shift to being more of a standalone mini-framework rather than a yii module..

You can see how other people have been building micro-frameworks using the symfony components, and that seems like an intriguing possibility for Yumps.

Unfortunately while yii feels absolutely natural and synchronized with the way i code, symfony is the opposite -- it feels alien, awkward, and ugly.

However, it's still something i'm thinking about, if only because using symfony components seems to offer some advantages in terms of having less of a commitment to pieces that are unrelated to Yumps.

mouser:
I have just finished a painful round of coding adding various options for how user registration should be done.

Traditionally (for example on most forums) when a new user wants to sign up, they are asked for a username, password, and email address.  At that point a validation email is sent to the users registered email address that they must click to prove that it their email, after which they can log in.

The new optional mode asks the user ONLY for an email address, and then forces the user to provide the other required fields (username, password) only after they have visited the validation link; this can be used with bridged accounts as well, and by default (though it is an option) will create only lightweight validation table entries until the validation is complete, which avoids polluting the user table with unvalidated failed accounts.

There are several advantages to the new method:

* Simpler initial registration, less confusion for users and less mental barrier to signing up
* The part that most often goes wrong (providing wrong email address) is caught early before user wastes any time -- and they haven't ended up "reserving" a username that they never follow through on.
* The user table is only validated users -- cleaner and smaller
Drawbacks:

* The use of a specialized pending-validation table *might* make it more programatically painful to report and track bad behavior.. That is if we created a non-validated user account right away, we could have one and only one unified system for tracking users behavior, ips, access attempts, log, etc.  Wheras if we postpone creating a user until validation, we need to provide investigatory tools both for the normal user table but also for the validation pre-registration table.
* If we only gather email address from user initially, we can't let them in right away, pending email validation, to access some limited areas, the way we could if we got their username and password initially.
* Any other drawbacks I'm not thinking of?
Note:

It's been particularly painful simultaneously supporting both this new method, as well as the traditional method of registration, as well as options for how to handle bridged logins in these cases, which introduces some hairy scenarios (like when you want to allow bridged users to not be forced to provide an email address, etc.)

Keeping the multiple options for user account registration may not be worth the extra complication in the long run, and I am thinking of dropping support for the traditional registration approach (get username,email,pass at initial signup).  If anyone has strong feelings either way let me know.

In general I'd say the thing that's really kicking my ass lately with YUMPS is trying to support options for having so many different ways to do things..

mouser:
I have not been focusing at all on looks, so this is nothing to be excited about, but here's the navigation sidebar in action:


Again, the themeing and style needs major work; the important thing is that there is a site navigation system that handles main menus, sidebars, breadcrumbs, etc.  So that when you make a custom web system you don't have to worry about such things.

40hz:
^I actually like the way that looks. It's clean and functional. Easy on the eyes - and doesn't have a lot of pointless bling to distract from getting things configured.

 :Thmbsup:

Navigation

[0] Message Index

[#] Next page

[*] Previous page