On Sat, Nov 6, 2010 at 7:20 AM, Martin Makundi <
martin.maku...@koodaripalvelut.com> wrote:

> Hi!
>
> >> I'm not scared that easily. Private members have a place and purpose.
> > Yes, please don't make us have to expose our private parts.
>
> ;) Here's a first attempt with few TODOs, however:
>

All right, let's take a look.


>   }
> +
> +  private Map<String, Component> componentIdMapAidedComponent = new
> HashMap<String, Component>();
>

So, you just added a new Map to all markup containers that keeps components
in it?  Why would you do that?  We already have a storage mechanism for
children of a markup container.  And, it takes less memory space than a
Map.  Why do we need two storage containers for children?  Why can't you
call add(foo) and get("fooID")?

+    {
> +      // Add also aided children to their right place; all should now
> exist in the map
> +      for (Component child : new
> LinkedList<Component>(componentIdMapAidedComponent.values() /** remove
> items from componentIdMapAidedComponent as soon as they are matched
> */))
> +      {
> +        /*
> +         * TODO Parse markup, find each component's real parent and add it
> onto
> +         * its real parent
> +         *
> +         * TODO MarkupVisitor must not visit child markup when they have
> their
> +         * own (maybe it's not even possible by default).
> +         *
> +         * TODO Throw exception if child id is matched multiple times.
> +         */
> +
>

Oh, so all that's left is to do all the real work?  :)


> +        // Finally remove aided component from map
> +        componentIdMapAidedComponent.remove(child.getId());
> +      }
> +    }
>

Like I mentioned in my previous response on this thread - you need to come
to us with everything you've got.  It needs to show us:

   - a real working solution
   - something that doesn't break existing stuff (real world apps, and
   passes all existing test cases)
   - test cases for itself and all new functionality
   - proof that it doesn't allow the designers to easily break security
   (like Igor's example)

I'm not trying to be difficult.  I'm simply saying that you have an uphill
battle ahead of you.  Many core committers have already told you that the
idea isn't real good.  Then you come with a "patch" that simply adds a
bloated second place to store children in all markup containers?  That's not
helping your case.

If you can truly present an elegant solution that solves all of the above,
we can consider it.  But don't bring us noise that is laughably incomplete.
Like Brian said, make a branch (you can fork the git mirror to make this
easier) and start some development.  This is not something that will be done
in an hour.  You're going to have to sink some time into it.  Do yourself
the favor of really working through the solution wholeheartedly.

-- 
Jeremy Thomerson
http://wickettraining.com
*Need a CMS for Wicket?  Use Brix! http://brixcms.org*

Reply via email to