Over the past few months, I''ve developed an administrative console for
databases in the process of solving other problems.
At the moment, the state of development is:
* Going to /admin_panel/model will bring you to a list of items in the
model:
* Supports acts_as_list via drag/drop sorting
* Supports "activated" via an activated/deactivated button
* Supports basic CRUD operations
* /admin_panel/model/edit will create a new instance of the model
* /admin_panel/model/edit/id will bring up an edit form
* the panel is customizable:
* by def page_options; { option_hash }; end
* by def list_options; { option_hash }; end
* /admin_pane/model will provide a two-panel categorized list if
:has_many
or :belongs_to options are set as a list_option
* Clicking a category (on the left list) will bring up items (from
the right
list) in that category. This works with working has_many or
belongs_to
relationships set in Rails.
* the edit form automatically created widgets for database columns of
type:
* :text with optional support for tinyMCE
* :string with a text_field
* :date with date_select
* :time with am/pm via a time_select plugin I heavily modified
* :boolean with a checkbox
* :file with file_column
* :image with file_column and an image display
* automatic select boxes for belongs_to
* the edit form can be customized (via page_options):
* fields can be ignored
* the default widget can be changed
* pretty field names can be created that are used in both labels and
error messages (via pretty_error_messages_for)
* the header can be changed from the default ("New Model Name" or
"Editing
Model Name(Title of Specific Items)
* The order of fields can be specified
* Subsection titles can be specified
* Lines can be removed under specific items
* Additional options can be specified for the widget (e.g. you can
pass
options for the text_field, date, etc. widgets that are merged with
the
default options)
* The back button can be added or removed
* Required conventions at the moment
* the main name field in a model is called ''title''
* this will probably change to become customizable
You can see a screenshot of the list view and the edit form at
http://www.yehudakatz.com/admin-console.gif
The point of this rather long explanation is to elicit feedback about
where I should go with this. I would like to release it as a plugin
(probably an Engine), and would like to make it more sanely put together
before I do so:
* GUI, database-held configuration via a AdminPanel model and
:serialize
* A central navbar for the tables
* Add and remove models from the admin panel via the GUI
* All of the above would replace the current hack of putting the config
in a
model method and make it easier for newbies to configure their
database
front-end
This tool, as it currently stands, does not assist in the creation of
tables. Because migrations are so easy (and important to know), I
figured that people could continue to create their models as they do
currently, and have an automated (but configurable) data-entry backend
without further work.
That''s what I needed anyway (for me, the configuration was needed so
that I could make the various forms look good, and not like some generic
throw-in; I''m using it as the back-end to a CMS I''m building
for a large
non-profit).
I''m looking forward to some feedback. Again, take a look at the
screenshot at
http://www.yehudakatz.com/admin-console.gif to get a better sense of
what all
of this means. Note that nothing in the screenshot was generated by
anything
but a group of universal helpers.
Thanks!
Yehuda Katz
--
Posted via http://www.ruby-forum.com/.
> * :text with optional support for tinyMCE > * :string with a text_field > * :date with date_select > * :time with am/pm via a time_select plugin I heavily modified > * :boolean with a checkbox > * :file with file_column > * :image with file_column and an image display > * automatic select boxes for belongs_toi remmeber the joy of clicking together Object.const_get(params[:type]).new and render :partial => Model.classname.to_s.underscore and more or less having a fully-featured app just from writing a migration. where i''d like to see this go is model editing. maybe theyll want to add a latitude field to the locations, or they want to start tagging eachothers tags, or maybe they added a few fields to a particular record, and want to save that as a template (''they'' as in the users, who dont know about migrations or editing rhtml). at least, this is what im working on . the main thing im undecided on is GPL vs Rails license, and ActiveRDF vs my pseudo-RDF on ActiveRecord . also, i dont think the association feature is docuemnted in a screenshot? thats the one im most curious about..> The point of this rather long explanation is to elicit feedback about > where I should go with this.wherever you want to go :)
carmen wrote:>> * :text with optional support for tinyMCE >> * :string with a text_field >> * :date with date_select >> * :time with am/pm via a time_select plugin I heavily modified >> * :boolean with a checkbox >> * :file with file_column >> * :image with file_column and an image display >> * automatic select boxes for belongs_to > > i remmeber the joy of clicking together > Object.const_get(params[:type]).new and render :partial => > Model.classname.to_s.underscore and more or less having a fully-featured > app just from writing a migration. where i''d like to see this go is > model editing. maybe theyll want to add a latitude field to the > locations, or they want to start tagging eachothers tags, or maybe they > added a few fields to a particular record, and want to save that as a > template (''they'' as in the users, who dont know about migrations or > editing rhtml). at least, this is what im working on . the main thing im > undecided on is GPL vs Rails license, and ActiveRDF vs my pseudo-RDF on > ActiveRecord . > > > also, i dont think the association feature is docuemnted in a > screenshot? thats the one im most curious about..There are two association features: * Dual-panel lists * Select-boxes for associations Dual panel lists just means that if you have a model with has_many in its options, and call the model, it''ll create a two-sided list that allows you to select a category from the left side and get a list of categories on the right side. Select boxes: Say you have model Person that has belongs_to :city. You would have a city_id field, and a City model (at the moment, with a column called ''title''). My form would automatically create a drop-down box in the Person form with a list of all city titles. You could choose to :ignore the city drop-down if, say, you were using a dual-panel list with City on the left and Person on the right (in that case, it''d be unnecessary to have the city drop-down).> >> The point of this rather long explanation is to elicit feedback about >> where I should go with this. > > > wherever you want to go :)Indeed. -- Yehuda -- Posted via http://www.ruby-forum.com/.